[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: builtin-commands + sash
From:       Luciano Rocha <strange () nsk ! no-ip ! org>
Date:       2008-01-28 9:56:07
Message-ID: 20080128095607.GA21713 () bit ! office ! eurotux ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Mon, Jan 28, 2008 at 04:26:26AM +0000, kalyanatejaswi balabhadrapatruni wrote:
> hi,
> Thanks for your pointers. Please see my concerns
> in-line.
> 
> --- Luciano Rocha <strange@nsk.no-ip.org> wrote:
> 
> > On Fri, Jan 25, 2008 at 10:48:15AM +0000,
> > kalyanatejaswi balabhadrapatruni wrote:
> > > Hi,
> > > I did "help" in sash shell and compared the output
> > to
> > > the commands i found in BB-1.9.0 as
> > > 1. shell/ash.c built-in commands and 
> > > 2. NOFORK (or even NOEXEC ) applets
> > > 
> > > And these are what i found missing in BB-1.9.0 as
> > > built-in commands:
> > > 
> > > aliasall,
> > 
> > Not applicable.
> > 
> > > setenv, quit, source
> > 
> > These must be in ash, if not under different name:
> > - setenv -> export var=val
> > - quit -> exit
> > - source -> source and .; could never be an external
> > command, like "cd"
> > 
> > > ar, chattr, cmp, ed, file, grep, gunzip,
> > > lsattr, mknod, more, mount, mv, printenv, prompt,
> > > sum, tar, umount, where
> > 
> > These should all be available, but they don't need
> > to be marked as
> > built-in. 
> But if they are not implemented as builtin, we are
> loosing primary advantage of built-in commands, i.e.,
> no forking overhead. Isnt it?

No, the advantage of builtin-commands is that they're always available
(as long as you can start the shell). So, if your system loses or
corrupts important files (libraries, ls/cat/mv/vi and other important
core programs), you can still execute a strimmed down version of those
commands.

The fork overhead is small under Linux, and most busybox aren't designed
to run all under the same process (most don't clean up after them,
change global variables, etc.).

> 
> If you can run ash, you can run the
> > others, if compiled in
> > busybox. You do have a configuration switch for
> > trying compiled-in
> > commands first.
> 
> Is CONFIG_FEATURE_SH_STANDALONE feature you are
> suggesting? As i understand, this feature helps in
> case my system is screwed up and busybox comes to the
> rescue with its commands.

Not quite. The busybox commands are always available (by running
busybox <command>), but your preferred commands (the ones in $PATH) may
be corrupted or missing[1] (think # rm -fr /), so this makes the
internal version the preferred ones.

> But again, it doesnt ensure
> "no forking" for non built-in commands. Isnt it? 

No, but, again, fork() under Unix is very cheap, and simpler to use than
to ensure proper clean up by all the commands supported by busybox.

[1] under linux, if running busybox without the CONFIGUE_SH_STANDALONE,
you can still execute busybox commands by using /proc/self/exe
<command>.

-- 
lfr
0/0

[Attachment #5 (application/pgp-signature)]

_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox

[prev in list] [next in list] [prev in thread] [next in thread]