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

Rob Landley rob at landley.net
Sun May 7 03:45:16 UTC 2006


On Saturday 06 May 2006 1:29 am, Denis Vlasenko wrote:
> > Needing to feed a decimal number into APPLET_DATA_SIZE is just evil.
>
> I agree. A better solution is?

I'm working on a "global struct in a union" version to see if I can make that 
work reasonably well.  I hope to get it done tomorrow, today got eaten by a 2 
hour house hunting trip turning into an almost 5 hour house hunting trip.  
Too tired to do anything when I got home after that.  (Ok, and my fiancee got 
me addicted to kingdom hearts on her praystation, but I've almost beaten 
that...)

> > Sticking BEGIN_BSS in the global declarations is black magic.
>
> Well, you need _some form_ of black magic anyway.

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.

> > 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...

> > The nofork bit and the global consolidation can be handled separately.
> > Consolidating the globals helps nommu platforms anyway, and is something
> > we should do first.  We can worry about nofork after we've made some
> > headway on that.  I'll convert sed to using a structure to begin with,
> > and see how that looks.
>
> Yes, as you probably noticed, I did not actually do the NOFORK bit itself
> :)
>
> Consolidating globals consists of consolidating bss and consolidating data.
> Data consolidation is done exactly like bss (that is, all data variables
> are to be put into a structure) with the addition of one
> memcpy(data_buffer, data_template, sizeof(struct DATA))

To confirm: bss is the prezeroed stuff and data is the initialized stuff?  
(And read only is separate from both?)

> > (Note: bunzip2 is already using such a structure, although if we
> > consolidate that and tar tries to use it without forking...)
>
> Prime candidates for NOFORK'ifying are those applets which may be
> frequently used in shell scripts in loops: cat, cp, mv, mkdir, cut,
> awk, sed, grep, basename, ...
> tar is not one of them.

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.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list