17:21:12 <richlowe> tsoome: can you look at the #15584 (fenix?) review?
17:21:14 <fenix> BUG 15584: misc. components use headers from the build machine (In Progress)
17:21:14 <fenix> ↳ https://www.illumos.org/issues/15584 | https://code.illumos.org/c/illumos-gate/+/2780
17:21:35 <richlowe> I'm not sure what libsa is trying to achieve, and I possibly made it more fragile (though nothing changes)
17:27:36 <tsoome> hm, something was missing /usr/include ?
17:44:33 <richlowe> libsa's asm was
17:44:51 <richlowe> so it used the build machine asm_linkage.h etc.
17:46:08 <richlowe> so I know that works, but in a similar manner to fk smb (which I'm leaving you and Gordon to deal with), the games you play with flag re-setting and stuff means I'm not sure if I'm making your stuff more fragile in the fix
18:17:39 <gwr> My expectation for fksmbd and related is that, on a "native" build (meaning the running OS is "close" to what's in the workspace) that the build results should be runnable from the proto area.
18:18:15 <richlowe> that's not relevant.  The question is whether it's a truly native tool (and should use these headers) or not (and shouldn't.)
18:18:32 <gwr> In such setups, the "adjuncts" area is the build machine, basically.
18:20:31 <richlowe> if it's truly native it should also be using NATIVE*
18:20:38 <richlowe> (and Makefile.native, when I get that into gate)
18:21:19 <richlowe> but I'm glad I didn't try to fix it, because that's definitely something you and toomas need to figure out :)
18:22:49 <gwr> I suspect that the way you're referring go "native" is where the target of the build is very different from the build machine, and where we don't want to assume that what we deliver can run on the build machine (eg cross compiling).  I don't think it's worth the trouble to build both "native" (in that sense) libraries and (separately) deliverable libraries for all the stuff fksmbd wants.
18:24:10 <gwr> In other words, I'm fine with fksmbd working only where the build machine is running something close to what's in the WE.
18:24:13 <gwr> WS
18:24:34 <richlowe> you'd be better saying this in the bug report!
18:24:41 <richlowe> (because I won't remember)
18:24:44 <gwr> What bug report?
18:25:00 <richlowe> https://www.illumos.org/issues/15582
18:25:02 <fenix> → BUG 15582: fk smb uses a bunch of build machine headers (New)
18:25:49 <gwr> It's there in the README, no?
18:27:47 <richlowe> no?
18:31:08 <richlowe> anyway, update the bug etc as you see fit.  What you're trying to explain is exactly the reason I left it to you and toomas
22:04:36 <tired> t
23:15:12 <dangergrrl> I am working on a project that may be of interest here
23:17:16 <dangergrrl> I'm working on linux for this project but what if procfs were extended to allow write
23:18:12 <dangergrrl> the limited case involves load balancing
23:18:32 <rmustacc> You may want to review proc(5), as we do allow writes for a lot of different aspects.
23:18:43 <rmustacc> And then there's also the agent-lwp for truly getting up in things.
23:19:03 <dangergrrl> ty rmustacc 
23:19:24 <dangergrrl> can i create a process from a saved image?
23:20:20 <dangergrrl> my linux case involves moving a running process from one machine to another
23:22:45 <dangergrrl> my student who i now work for thinks it should all be kernel code, i think procfs should handle most of it in this use case
23:23:41 <dangergrrl> why use kernel level code when you can do most of it in userspace
23:24:35 <dangergrrl> and yes i prefer unix to linux
23:24:46 <rmustacc> With the agent-lwp you can do a lot shenanigans on illumos.
23:24:59 <rmustacc> But can you create a process from a saved image, no, not inherently.
23:26:38 <dangergrrl> how much work would this be and would it be accepted?
23:27:33 <dangergrrl> getting a core dump is easy
23:27:51 <rmustacc> How much work? Probably non-trivial to get it all working and full of caveats.
23:28:02 <rmustacc> Because there are a lot of things like sockets and other things being there.
23:28:25 <rmustacc> I would suggest figuring out what the use case is.
23:28:33 <dangergrrl> sockets are one of our hardest problems even on linux
23:29:24 <dangergrrl> rmustacc, the use case is load balancing on clusters right now but the next use case is fault tolerance
23:30:17 <dangergrrl> i did work for tandem who make systems that never die
23:31:16 <dangergrrl> right now the use case is load balancing
23:32:07 <dangergrrl> but i never fail is a goal
23:32:48 <dangergrrl> i don't have the hardware to even start on that one
23:33:19 <dangergrrl> you need infiniband or equivalent
23:39:26 <dangergrrl> the sockets and the file system are what i see sticking us
23:43:40 <dangergrrl> on linux i could do most of it in userspace