NOFORK
NOFORK applet should work correctly if another applet simply runs
-<applet>_main(argc,argv) and then continues with its business (xargs,
-find, shells can do it). This poses much more serious limitations
-on what applet can/cannot do:
+<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:
* all NOEXEC limitations apply.
* do not ever exit() or exec().
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
- prior to returning. (e.g. bb_common_bufsiz1 is off-limits).
+ (e.g. bb_common_bufsiz1) prior to returning.
- 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
are probably not worth the effort.
Any NOFORK applet is also a NOEXEC applet.
+
+
+ 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