[BusyBox] fork / vfork in init.c

[Erik Andersen]

On Fri Oct 22, 2004 at 04:11:24PM -0500, Rob Landley wrote:
> Init used to be using vfork (up until recently), which is needed on certain 
> mutant mmu-less systems that can't fork properly.  It seems to have been 
> taken out recently (to fix a bug caused by inappropriate use of vfork on 
> systems that DO have an MMU), and the above patch is trying to put it back.

The only time BusyBox init used vfork was when people used the
latest BusyBox with an old version of uClibc.  This was
inadvertant, due to a naming convention change for a particular
uClibc config option.

> The fork calls that _init_ makes have, indeed, been tested to work with vfork, 

Well, not really.  They were tested and found broken when using
vfork, which was why people complained about init using vfork
when it was not vfork safe.

> in certain cases.  But only in certain cases, and it's icky to use vfork on a 
> system that has a working fork anyway.  Even some mmu-less systems seem to 
> have a working fork, so the above #ifdef is insufficient.

There are _no_ uClinux (mmu-less) systems with a working fork.
To fork, the operating system must be able to do copy-on-write
(COW), and to do COW, you have to have an mmu[1].

> Probably the cleanest way to deal with it is a config option:
> "init uses vfork", that defaults to N.

I'd rather not do that.  It would be better to add a
	[X] I am using uClinux
type config option, and make busybox init depend on !uClinux.  bb
init is simply not vfork safe, and adding such a config option is
not going to make it any safer.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--