additional applets available as ash builtins?

[Denys Vlasenko]

On Saturday 12 April 2008 22:13, Cristian Ionescu-Idbohrn wrote:
> Great.  Thanks a lot fo the information.
> 
> On Sat, 12 Apr 2008, Denys Vlasenko wrote:
> 
> > There are special subsets of applets called NOFORK and NOEXEC applets:
> >
> > # grep '^U.*NOFORK' include/applets.h
> 
> ...
> 
> > # grep '^U.*NOEXEC' include/applets.h
> 
> ...
> 
> > From your list above, kill is already a builtin,
> 
> Hmm... I don't see it.  include/applets.h says:
> 
>   USE_KILL(APPLET(kill, _BB_DIR_BIN, _BB_SUID_NEVER))
> 
> meaning kill isn't a NOFORK/NOEXEC applet?

Yes, it isn't. It can probably made to be one.
As I said, there were no focused campaign to make
more applets NOFORK/NOEXEC. (hint: you can do it)

However, in ash "kill" is indeed handled specially (as a builtin),
mostly because it has to support "kill %JOBNUM":

static int
killcmd(int argc, char **argv)
{
        int i = 1;
        if (argv[1] && strcmp(argv[1], "-l") != 0) {
                do {
...handle %JOBNUM...
                } while (argv[++i]);
        }
        return kill_main(argc, argv);
}
...
/* Keep these in proper order since it is searched via bsearch() */
static const struct builtincmd builtintab[] = {
...
#if JOBS
        { BUILTIN_REGULAR       "jobs", jobscmd },
        { BUILTIN_REGULAR       "kill", killcmd },
#endif

> Thanks for the explanation.  I knew there was something I missed.  So the
> key to better shell performance would be enabling:
> 
>   FEATURE_SH_STANDALONE
> 	This option causes busybox shells to use busybox applets
> 	in preference to executables in the PATH whenever possible.  For
> 	example, entering the command 'ifconfig' into the shell would cause
> 	busybox to use the ifconfig busybox applet.  Specifying the fully
> 	qualified executable name, such as '/sbin/ifconfig' will still
> 	execute the /sbin/ifconfig executable on the filesystem.
> 
> which also enables:
> 
>   FEATURE_PREFER_APPLETS
> 	This is an experimental option which directs applets about to
> 	call 'exec' to try and find an applicable busybox applet before
> 	searching the PATH. This is typically done by exec'ing
> 	/proc/self/exe.
> 
> And then expect faster execution of applets located with:
> 
>   # egrep '^U.*NO(EXEC|FORK)' include/applets.h | \
>   cut -d'(' -f3 | cut -d, -f2 | tr ' ' '\t' | sort
>         awk
>         basename
>         cat
>         chgrp
>         chmod
>         chown
>         cp
>         cut
>         dd
>         dirname
>         echo
>         false
>         find
>         hexdump
>         hostid
>         length
>         ln
>         logname
>         ls
>         mkdir
>         pwd
>         rm
>         rmdir
>         seq
>         sleep
>         sort
>         sync
>         tac
>         test
>         test
>         touch
>         true
>         usleep
>         whoami
>         xargs
>         yes
> 
> That means these applets:
> 
> 	date
> 	env
> 	expr
> 	head
> 	kill
> 	mktemp
> 	pgrep
> 	pidof
> 	pkill
> 	printf
> 	readlink
> 	realpath
> 	stat
> 	tail
> 	uniq
> 	wc
> 	which
> 
> could be NO(EXEC|FORK) candidates.

Exactly. Also we'll need to review where in shell we can avoid not only
exec()ing, but fork()ing too. IOW: shells to date were not using
NOFORKiness of some applets to full extent.
--
vda