Re: RFC: import of posix_spawn GSoC results

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> On Wed, Jan 25, 2012 at 01:14:18PM +0000, YAMAMOTO Takashi wrote:
>> hi,
>> 
>> > On Wed, Jan 25, 2012 at 12:50:12PM +0100, Martin Husemann wrote:
>> >> A working alternative aproach to this patch is to use a vfork based 
>> >> emulation
>> >> in userland only (FreeBSD is doing that). It is less kernel code, but to
>> >> me sounds a bit hackish and/or fragile - maybe a matter of personal taste.
>> > 
>> > As said earlier, this can fail pretty badly when libraries (think pth)
>> > overwrite system calls to do "transparent" operations behind the back.
>> > Our mutexes for example are process specific.
>> 
>> i don't understand.  can you explain?
>> 
>> posix_spawn, if implemented in userland, is supposed to be in libc
>> and thus can use the raw versions of system calls without being fooled
>> by such libraries.
> 
> There is for example this "rump" thing that likes to mess with them even
> on the raw level. I feel quite a bit more comfortable with a kernel
> implementation. The issues Martin run into are bad refactoring and
> fragile kernel code -- which should be cleaned up in any case.

what's "rump" thing and how it benefits from a kernel implementation?

do you mean rumphijack?  iirc it sits between application and libc.

YAMAMOTO Takashi

> 
> Joerg