[BusyBox] pre-commit feedback, please

[Rob Landley]

On Friday 29 July 2005 00:37, Mike Frysinger wrote:
> On Friday 29 July 2005 01:08 am, Rob Landley wrote:
> > > 0000132 03-16-05 Implement fork using longjmp
> > >     [ somewhat controversial, i recall... ]
> >
> > It is.  This is a libc thing, not a busybox thing.  I object to having it
> > in busybox on that grounds.
> >
> > That said: the whole mess of figuring out when we need to vfork and when
> > we need a real fork is a bit of a nightmare right now anyway.  If we
> > wanted to clean up ALL that (I could see "use vfork instead of real fork"
> > under "general configuration" next to "free memory before exiting"), and
> > add this as a third option to a three way (fork/vfork/longjmp) selector
> > that selects a bb_spork() helper function in its own darn file, then it
> > becomes a lot more palatable.
> >
> > This could tangentially be related to the "compiler.h" cleanup I
> > mentioned earlier, and the fork/exec/wait combo helper function.  I.E.
> > this is 1.1 material, but it's not a no-brainer to check in in its
> > present form.
>
> erik would be able to add more info to this topic in general ...

Presumably saturday. :)

> here's the situation as i understand (i may be wrong, i dont use uClinux
> :P): busybox is already full of __uClinux__ checks simply because fork is
> not support on that kernel ...

And that's for historical reasons: I believe Erik used to work for them and 
they sponsored uClibc and busybox development.  That hasn't been the case for 
quite some time, and in _theory_ there's no reason for busybox to have 
special cases for any of this stuff.  uClinux is _not_ the only embedded 
Linux distro, it isn't even the most widely used one.  (Linksys routers don't 
use it, and there's zillions of those.)

In practice, a menuconfig entry for systems that don't fork properly and need 
something else makes sense, if it's all in one place.

> then there's the topic of libgloss ... some people wish to run busybox as a
> standalone program (that is, no kernel at all) and i *think* that this kind
> of feature support would be a boon to them as well

Yup.  But if we're going to do this at all, we should do it right.  Don't add 
one more special case, and do _NOT_ #define fork() something_that_isn't_fork.  
We should call bb_fork and friends everywhere and let the logic in there 
figure out whether it needs vfork or longjmp based on menuconfig stuff, and 
rip out all the current horrible #ifdef tests that check and see if we need 
to fork or vfork.

Yeah, it's a more intrusive patch, but it's the right thing to do.  If you 
want to "#define fork() break_the_build=42;" for debugging purposes, fine, 
but don't check that in.

P.S.  the test in libbb.h, "#if CONFIG_FEATURE..." won't work if it's 
disabled, will it?  Undefined symbol.  That's not an #ifdef.  So this patch 
couldn't go in as-is anyway...

Rob