2007-04-11 16:16:41 +00:00
|
|
|
NOEXEC and NOFORK applets.
|
|
|
|
|
|
|
|
Unix shells traditionally execute some commands internally in the attempt
|
|
|
|
to dramatically speed up execution. It will be slow as hell if for every
|
2008-01-06 06:27:17 +00:00
|
|
|
"echo blah" shell will fork and exec /bin/echo. To this end, shells
|
2007-04-11 16:16:41 +00:00
|
|
|
have to _reimplement_ these commands internally.
|
|
|
|
|
|
|
|
Busybox is unique in this regard because it already is a collection
|
|
|
|
of reimplemented Unix commands, and we can do the same trick
|
|
|
|
for speeding up busybox shells, and more. NOEXEC and NOFORK applets
|
|
|
|
are exactly those applets which are eligible for these tricks.
|
|
|
|
|
|
|
|
Applet will be subject to NOFORK/NOEXEC tricks if it is marked as such
|
2008-01-06 06:27:17 +00:00
|
|
|
in applets.h. FEATURE_PREFER_APPLETS is a config option which
|
2007-05-30 00:29:55 +00:00
|
|
|
globally enables usage of NOFORK/NOEXEC tricks.
|
2008-01-06 06:27:17 +00:00
|
|
|
If it is enabled, FEATURE_SH_STANDALONE can be enabled too,
|
|
|
|
and then shells will use NOFORK/NOEXEC tricks for ordinary commands.
|
|
|
|
NB: shell builtins use these tricks regardless of FEATURE_SH_STANDALONE
|
|
|
|
or FEATURE_PREFER_APPLETS.
|
2007-04-11 16:16:41 +00:00
|
|
|
|
2008-01-06 06:27:17 +00:00
|
|
|
In C, if you want to call a program and wait for it, use
|
|
|
|
spawn_and_wait(argv), BB_EXECVP(prog,argv) or BB_EXECLP(prog,argv0,...).
|
|
|
|
They check whether program name is an applet name and optionally
|
|
|
|
do NOFORK/NOEXEC thing depending on configuration.
|
2007-04-11 16:16:41 +00:00
|
|
|
|
2008-01-06 06:27:17 +00:00
|
|
|
|
|
|
|
NOEXEC
|
2007-04-11 16:16:41 +00:00
|
|
|
|
|
|
|
NOEXEC applet should work correctly if another applet forks and then
|
|
|
|
executes exit(<applet>_main(argc,argv)) in the child. The rules
|
|
|
|
roughly are:
|
|
|
|
|
|
|
|
* do not expect shared global variables/buffers to be in their
|
|
|
|
"initialized" state. Examples: xfunc_error_retval can be != 1,
|
|
|
|
bb_common_bufsiz1 can be scribbled over, ...
|
|
|
|
* do not expect that stdio wasn't used before. Calling set[v]buf()
|
|
|
|
can be disastrous.
|
|
|
|
* ...
|
|
|
|
|
|
|
|
NOEXEC applets save only one half of fork+exec overhead.
|
2008-01-06 06:27:17 +00:00
|
|
|
NOEXEC trick is disabled for NOMMU build.
|
|
|
|
|
2007-04-11 16:16:41 +00:00
|
|
|
|
2008-01-06 06:27:17 +00:00
|
|
|
NOFORK
|
2007-04-11 16:16:41 +00:00
|
|
|
|
|
|
|
NOFORK applet should work correctly if another applet simply runs
|
2011-02-02 17:38:57 +00:00
|
|
|
<applet>_main(argc,argv) and then continues with its business.
|
|
|
|
xargs, find, shells do it (grep for "spawn_and_wait" and
|
|
|
|
"run_nofork_applet" to find more users).
|
|
|
|
|
|
|
|
This poses much more serious limitations on what applet can do:
|
2007-04-11 16:16:41 +00:00
|
|
|
|
|
|
|
* all NOEXEC limitations apply.
|
|
|
|
* do not ever exit() or exec().
|
|
|
|
- xfuncs are okay. They are using special trick to return
|
|
|
|
to the caller applet instead of dying when they detect "x" condition.
|
|
|
|
- you may "exit" to caller applet by calling xfunc_die(). Return value
|
|
|
|
is taken from xfunc_error_retval.
|
|
|
|
- fflush_stdout_and_exit(n) is ok to use.
|
|
|
|
* do not use shared global data, or save/restore shared global data
|
2011-02-02 17:38:57 +00:00
|
|
|
(e.g. bb_common_bufsiz1) prior to returning.
|
2007-04-11 16:16:41 +00:00
|
|
|
- getopt32() is ok to use. You do not need to save/restore option_mask32,
|
|
|
|
it is already done by core code.
|
|
|
|
* if you allocate memory, you can use xmalloc() only on the very first
|
|
|
|
allocation. All other allocations should use malloc[_or_warn]().
|
|
|
|
After first allocation, you cannot use any xfuncs.
|
2008-01-06 06:27:17 +00:00
|
|
|
Otherwise, failing xfunc will return to caller applet
|
|
|
|
without freeing malloced data!
|
2007-04-11 16:16:41 +00:00
|
|
|
* All allocated data, opened files, signal handlers, termios settings,
|
|
|
|
O_NONBLOCK flags etc should be freed/closed/restored prior to return.
|
|
|
|
* ...
|
|
|
|
|
|
|
|
NOFORK applets give the most of speed advantage, but are trickiest
|
|
|
|
to implement. In order to minimize amount of bugs and maintenance,
|
|
|
|
prime candidates for NOFORK-ification are those applets which
|
|
|
|
are small and easy to audit, and those which are more likely to be
|
|
|
|
frequently executed from shell/find/xargs, particularly in shell
|
|
|
|
script loops. Applets which mess with signal handlers, termios etc
|
|
|
|
are probably not worth the effort.
|
|
|
|
|
|
|
|
Any NOFORK applet is also a NOEXEC applet.
|
2011-02-02 17:38:57 +00:00
|
|
|
|
|
|
|
|
|
|
|
Relevant CONFIG options
|
|
|
|
|
|
|
|
FEATURE_PREFER_APPLETS
|
|
|
|
BB_EXECVP(cmd, argv) will try to exec /proc/self/exe
|
|
|
|
if command's name matches some applet name
|
|
|
|
applet tables will contain NOFORK/NOEXEC bits
|
|
|
|
spawn_and_wait(argv) will do NOFORK/NOEXEC tricks
|
|
|
|
|
|
|
|
FEATURE_SH_STANDALONE (needs FEATURE_PREFER_APPLETS=y)
|
|
|
|
shells will try to exec /proc/self/exe if command's name matches
|
|
|
|
some applet name
|
|
|
|
shells will do NOEXEC trick on NOEXEC applets
|
|
|
|
|
|
|
|
FEATURE_SH_NOFORK (needs FEATURE_PREFER_APPLETS=y)
|
|
|
|
shells will do NOFORK trick on NOFORK applets
|