[BusyBox] pre-commit feedback, please

[Erik Andersen]

On Fri Jul 29, 2005 at 01:41:53AM -0500, Rob Landley wrote:
> > erik would be able to add more info to this topic in general
> > ...
> 
> Presumably saturday. :)

Took the 4th off for my birthday -- I'm now the big 34...

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

You are a bit confused here.  The 'them' you are referring to
appears to be uClinux, which is not a company at all...  It is a
version of the Linux kernel modified to run on a mmu-less
processors (i.e. microcontrollers, hense the name u for micro, C
for controller, Linux.  uClinux).  These days, Linux isn't even
modified really, as mmu-less support for several platforms is now
included in the stock Linux 2.6 kernel series.  With an mmu-less
processor running uClinux, the kernel cannot fork because it
cannot do Copy On Write (COW), and thus uClinux systems must use
pthreads or vfork (parent and child share address space, parent
is suspend till child exits or calls exec()).  There are actually
methods whereby one could actually implement fork on an mmu-less
system (such as by implementing a full Copy Just In Case There
Might Be a Fork on each and every context switch) but such things
would have horrible performance and are not implemented in
uClinux.  So fork() on uClinux isn't allowed...

<begin long winded boring bits of history>
It is true that many moons ago I worked for a company called
Lineo (since purchased, gutted, and basically defunct), and while
there I worked with the folks from rt-control.com who created
uClinux and did the initial kernel work (rt-control was purchased
by Lineo, screwed over, then spun off again as
arcturusnetworks.com).  In the process of doing an mmu-less arm
uClinux port for the Atmel AT91 using as I recall (kernel 2.0.38)
I was annoyed at the total lack of coordination with all curent
uClinux work, and so with the help of the folk at rt-control I
setup http://cvs.uclinux.org/ which continues to be used
substantially unchanged from how I set it up...
</begin long winded boring bits of history>

Perhaps the distro you are thinking of is uClinux-dist, which is
a linux meta distro geared towards rolling your own uClinux
distro.  It is non-commercial, somewhat similar to buildroot and
targets many platforms (some with and some without an mmu).  Open
source.  Works.  Not my personal preferred method of doing
things, but not bad as such things go and widely used. 

> 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

A while back someone privately submitted an initial
uClibc/libgloss port.  It needed more work and much polishing,
but would actually make it running busybox on the bare metal a
fairly feasible prospect.  I still have that patch someplace
should anybody wish to carry on the torch towards removing this
amusing comment I added to uClibc years ago:

    http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/README?rev=1287&view=auto

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

I don't have a problem with the concept of a bb_fork.  But
bb_fork can never be just pid_t bb_fork(void) { return vfork(); }
Problem is, vfork can't be blindly dropped in as a replacement
for fork, since code written assuming fork semantics tends to
blow chunks and die when vfork lets the child muck about with the
contents of the parent's stack, or the child blocks the parent
forever because it thinks the parent also gets a chance to run,
etc.  Code using vfork must be specifically designed to use vfork
semantics.

 -Erik

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