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

[Denis Vlasenko]

On Sunday 07 May 2006 06:45, Rob Landley wrote:
> 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...)

I'm lucky because I have neither of 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.

What kind of breakage do you have in mind? A missed bss object?
Or incorrect BSS_SIZE_sed value?

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

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

Yes.

> (And read only is separate from both?)

That one does not need any special handling due to read-only-ness.

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

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...)
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox.bss_reduction3.patch
Type: text/x-diff
Size: 4340 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20060510/490f2da5/attachment.bin