[BusyBox] pre-commit feedback, please

[Rob Landley]

On Friday 05 August 2005 04:35, Erik Andersen wrote:
> 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...

More than one congratulation, then. :)
> You are a bit confused here.

Not the first time.

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

Okay, I thought it was a specific distro and had as much of a company behind 
it as Yellow Dog...

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

Gotcha.  So uClinux is any Linux kernel compiled with CONFIG_MMU off.


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

How does buildroot interact with this, then?

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

Something doing longjmp could also get a little confused if state it thought 
was child-private isn't.  Sounds like approximately the same kind of 
auditing, really.

Not a small project, though.  And almost certainly per-applet.  And an 
automated regression test suite would be nice, but that would be nice 
anyway...

>  -Erik

Rob