My os has no fork/exec - can I use busybox?

Denys Vlasenko vda.linux at googlemail.com
Sat Nov 7 00:39:48 UTC 2009


On Saturday 07 November 2009 00:13, Mike Frysinger wrote:
> On Friday 06 November 2009 19:04:02 Denys Vlasenko wrote:
> > On Thursday 05 November 2009 23:19, busby1 at llnl.gov wrote:
> > > I'm writing user-level code on a high performance computer (IBM Blue
> > > Gene).  The OS is missing some system calls, including fork/exec.
> > 
> > Without fork, you only lose ash applet.
> > 
> > But without exec, stock busybox is nearly useless.
> > 
> > The biggest problem is not that exec is not available
> > (a fair number of applets don't need exec - like cp),
> > but the fact that in many cases bbox is happily
> > aborts on errors and/or doesn't bother to clean up
> > allocated memory, open files etc,
> > knowing that returning from main() will exit and
> > kernel will do it anyway.
> > 
> > If you simply call <applet>_main(), it may exit on error
> > or leak resources - this is not what you want.
> > 
> > The only applets which are safe to use in this case are
> > NOFORK applets:
> 
> does NOFORK cover just the exit, or both exit and resource clean up?  i'm 

NOFORK applet should be completely clean on both fronts
in order to be NOFORK-safe.

> wondering if we can reuse the NOFORK markings in the shell so we dont have to 
> recreate builtins for each one.

It already does if FEATURE_SH_STANDALONE=y

The biggest problem is that NOFORK applets called from shell
change finer details of their execution. Such as:

# usleep 999999
^C  <-- oops! ^C gets delivered *to the shell* since there is no
        separate "usleep" process anymore...

> someone on the uClinux mailing list pointed  
> out that every avoided exec on an XIP system is a huge savings.

--
vda


More information about the busybox mailing list