tsoome: can you look at the #15584 (fenix?) review?

BUG 15584: misc. components use headers from the build machine (In Progress)

↳ illumos.org/issues/15584 | code.illumos.org/c/illumos-gate/+/2780

I'm not sure what libsa is trying to achieve, and I possibly made it more fragile (though nothing changes)

hm, something was missing /usr/include ?

libsa's asm was

so it used the build machine asm_linkage.h etc.

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

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.

that's not relevant. The question is whether it's a truly native tool (and should use these headers) or not (and shouldn't.)

In such setups, the "adjuncts" area is the build machine, basically.

if it's truly native it should also be using NATIVE*

(and Makefile.native, when I get that into gate)

but I'm glad I didn't try to fix it, because that's definitely something you and toomas need to figure out :)

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.

In other words, I'm fine with fksmbd working only where the build machine is running something close to what's in the WE.

WS

you'd be better saying this in the bug report!

(because I won't remember)

What bug report?

→ BUG 15582: fk smb uses a bunch of build machine headers (New)

It's there in the README, no?

no?

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

t

I am working on a project that may be of interest here

I'm working on linux for this project but what if procfs were extended to allow write

the limited case involves load balancing

You may want to review proc(5), as we do allow writes for a lot of different aspects.

And then there's also the agent-lwp for truly getting up in things.

ty rmustacc

can i create a process from a saved image?

my linux case involves moving a running process from one machine to another

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

why use kernel level code when you can do most of it in userspace

and yes i prefer unix to linux

With the agent-lwp you can do a lot shenanigans on illumos.

But can you create a process from a saved image, no, not inherently.

how much work would this be and would it be accepted?

getting a core dump is easy

How much work? Probably non-trivial to get it all working and full of caveats.

Because there are a lot of things like sockets and other things being there.

I would suggest figuring out what the use case is.

sockets are one of our hardest problems even on linux

rmustacc, the use case is load balancing on clusters right now but the next use case is fault tolerance

i did work for tandem who make systems that never die

right now the use case is load balancing

but i never fail is a goal

i don't have the hardware to even start on that one

you need infiniband or equivalent

the sockets and the file system are what i see sticking us

on linux i could do most of it in userspace