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