[3320] | 1 | NOEXEC and NOFORK applets.
|
---|
| 2 |
|
---|
| 3 | Unix shells traditionally execute some commands internally in the attempt
|
---|
| 4 | to dramatically speed up execution. It will be slow as hell if for every
|
---|
| 5 | "echo blah" shell will fork and exec /bin/echo. To this end, shells
|
---|
| 6 | have to _reimplement_ these commands internally.
|
---|
| 7 |
|
---|
| 8 | Busybox is unique in this regard because it already is a collection
|
---|
| 9 | of reimplemented Unix commands, and we can do the same trick
|
---|
| 10 | for speeding up busybox shells, and more. NOEXEC and NOFORK applets
|
---|
| 11 | are exactly those applets which are eligible for these tricks.
|
---|
| 12 |
|
---|
| 13 | Applet will be subject to NOFORK/NOEXEC tricks if it is marked as such
|
---|
| 14 | in applets.h. FEATURE_PREFER_APPLETS is a config option which
|
---|
| 15 | globally enables usage of NOFORK/NOEXEC tricks.
|
---|
| 16 | If it is enabled, FEATURE_SH_STANDALONE can be enabled too,
|
---|
| 17 | and then shells will use NOFORK/NOEXEC tricks for ordinary commands.
|
---|
| 18 | NB: shell builtins use these tricks regardless of FEATURE_SH_STANDALONE
|
---|
| 19 | or FEATURE_PREFER_APPLETS.
|
---|
| 20 |
|
---|
| 21 | In C, if you want to call a program and wait for it, use
|
---|
| 22 | spawn_and_wait(argv), BB_EXECVP(prog,argv) or BB_EXECLP(prog,argv0,...).
|
---|
| 23 | They check whether program name is an applet name and optionally
|
---|
| 24 | do NOFORK/NOEXEC thing depending on configuration.
|
---|
| 25 |
|
---|
| 26 |
|
---|
| 27 | NOEXEC
|
---|
| 28 |
|
---|
| 29 | NOEXEC applet should work correctly if another applet forks and then
|
---|
| 30 | executes exit(<applet>_main(argc,argv)) in the child. The rules
|
---|
| 31 | roughly are:
|
---|
| 32 |
|
---|
| 33 | * do not expect shared global variables/buffers to be in their
|
---|
| 34 | "initialized" state. Examples: xfunc_error_retval can be != 1,
|
---|
| 35 | bb_common_bufsiz1 can be scribbled over, ...
|
---|
| 36 | * do not expect that stdio wasn't used before. Calling set[v]buf()
|
---|
| 37 | can be disastrous.
|
---|
| 38 | * ...
|
---|
| 39 |
|
---|
| 40 | NOEXEC applets save only one half of fork+exec overhead.
|
---|
| 41 | NOEXEC trick is disabled for NOMMU build.
|
---|
| 42 |
|
---|
| 43 |
|
---|
| 44 | NOFORK
|
---|
| 45 |
|
---|
| 46 | NOFORK applet should work correctly if another applet simply runs
|
---|
| 47 | <applet>_main(argc,argv) and then continues with its business (xargs,
|
---|
| 48 | find, shells can do it). This poses much more serious limitations
|
---|
| 49 | on what applet can/cannot do:
|
---|
| 50 |
|
---|
| 51 | * all NOEXEC limitations apply.
|
---|
| 52 | * do not ever exit() or exec().
|
---|
| 53 | - xfuncs are okay. They are using special trick to return
|
---|
| 54 | to the caller applet instead of dying when they detect "x" condition.
|
---|
| 55 | - you may "exit" to caller applet by calling xfunc_die(). Return value
|
---|
| 56 | is taken from xfunc_error_retval.
|
---|
| 57 | - fflush_stdout_and_exit(n) is ok to use.
|
---|
| 58 | * do not use shared global data, or save/restore shared global data
|
---|
| 59 | prior to returning. (e.g. bb_common_bufsiz1 is off-limits).
|
---|
| 60 | - getopt32() is ok to use. You do not need to save/restore option_mask32,
|
---|
| 61 | it is already done by core code.
|
---|
| 62 | * if you allocate memory, you can use xmalloc() only on the very first
|
---|
| 63 | allocation. All other allocations should use malloc[_or_warn]().
|
---|
| 64 | After first allocation, you cannot use any xfuncs.
|
---|
| 65 | Otherwise, failing xfunc will return to caller applet
|
---|
| 66 | without freeing malloced data!
|
---|
| 67 | * All allocated data, opened files, signal handlers, termios settings,
|
---|
| 68 | O_NONBLOCK flags etc should be freed/closed/restored prior to return.
|
---|
| 69 | * ...
|
---|
| 70 |
|
---|
| 71 | NOFORK applets give the most of speed advantage, but are trickiest
|
---|
| 72 | to implement. In order to minimize amount of bugs and maintenance,
|
---|
| 73 | prime candidates for NOFORK-ification are those applets which
|
---|
| 74 | are small and easy to audit, and those which are more likely to be
|
---|
| 75 | frequently executed from shell/find/xargs, particularly in shell
|
---|
| 76 | script loops. Applets which mess with signal handlers, termios etc
|
---|
| 77 | are probably not worth the effort.
|
---|
| 78 |
|
---|
| 79 | Any NOFORK applet is also a NOEXEC applet.
|
---|