[PATCH 2/2] first stab at NOFORK applet support

[Rob Landley]

On Wednesday 10 May 2006 2:36 am, Denis Vlasenko wrote:
> > Manually maintained black magic is the worst kind.  It's ok if you do it
> > once and it works for all users.  At the very least if the build breaks
> > if you don't do it right in such a way that you get an obvious and
> > preferably informative error message.
>
> What kind of breakage do you have in mind? A missed bss object?
> Or incorrect BSS_SIZE_sed value?

Just generally having the sizes wrong.  I'm all for build time breakage, 
because we notice that before it eats anybody's data or gets deployed and 
fails in the field.  Run-time breakage has a chance to actually ship, which 
would suck.

> > > > The list of #defines for each global variable is just icky.
> > >
> > > An alternative is to do s/var/B.var/g. This will affect entire body
> > > of the applet, uglifying it a bit.
> >
> > Never programmed in python, have you? :)
> >
> > We could always call it "this", just to seriously tick off the C++
> > crowd...
>
> You are evil. ;)

It's a hobby.

> > The global variable consolidation isn't _just_ for nofork, it's also
> > useful for NOMMU systems.  They can't map the zero page and copy on
> > write, they have to allocate all the memory for all the globals.
>
> Good point. I looked at reducing bss (got it from 1+ meg to 200k),
> but didn't test it yet. See attached patch. Is it ok to allocate ~700k via
> alloca? (I'm entirely unfamiliar with nommu arch...)

Alas, no.  Fun things to know about nommu systems:

Memory fragmentation is a problem for them.  One big thing an mmu does is turn 
scattered physical pages into contiguous virtual address space, and without 
that you can have enough free memory but not enough _consecutive_ free memory 
to satisfy an allocation.  The workaround is to allocate as much as possible 
up front and then don't free it until you exit, to avoid allocations failing 
in the middle of the program run due to fragmentation and also so that what 
you're freeing when you exit is a big consecutive chunk the next program can 
fit into.

Their stack doesn't grow dynamically.  They can't put a guard page at the end 
and fault when they hit it.  So they have to preallocate as much stack space 
as they need, and can't detect a stack overflow at runtime.  This combines 
badly with the memory fragmentation thing, since the stack has to be 
consecutive pages.  Two or three copies of the same running executable can 
share the executable pages, but they need their own stacks.

The whole fork vs vfork thing, which there's a writeup of in the new FAQ 
that'll be going up in a few minutes.

When using mmap(), you can do MAP_SHARED but not MAP_PRIVATE.

Those are the big ones, I think.

Rob
-- 
Never bet against the cheap plastic solution.