I got to thinking.... about shells, busybox, and /linuxrc....
Using a new shell could let one replace ash (100k) AND busybox (175k) if
it had sufficient facilities incorporated within it. A language such as
ksh has a dual nature: one, it is an interactive command line to permit
users to do what they need and run programs; two, it is a language to
tie other programs together (such as piping output from ls into grep
into...)
During the boot process, there is no need for an interactive shell; a
full scripting language would be just the thing, and could replace 275k
in binaries with a 96k binary (in the case of lua). Perl and Ruby
remain too big, and awk may not include the necessary primitives (though
it would probably be too big anyhow).
With this concept, it makes for many more ideas and acceptable shells.
However, the problem remains: both ash and busybox are required. This
means that whatever shell or language is chosen, it most be ADDED to the
disk without taking anything away. However, such a shell would be a
perfect use for loading a disk from the network - one which was
particularly designed for this purpose.
Another thing: if the shell is complete enough, and the required
binaries are kept to a minimum, and are statically linked, then the C
libraries can be done away with and put into libc.lrp...
One benefit of using a more powerful shell that it also helps the system
to be more upgradable, since ash.lrp and busybox.lrp could be put in;
however, replacing busybox.lrp in a running system with busybox included
would require not using busybox during the actual unpacking of busybox,
or at least copying it over into the appropriate place when done - or
perhaps, putting it somewhere else when packaged up (like /usr/local/bin
instead of /bin). When using an alternative shell, this isn't a
problem; if the busybox.lrp is to be portable, it IS a problem.
The other problem with busybox is that it may include different commands
that are already in the system, but this may be not as much of a problem
as one might think. It would really be nice to make an ash.lrp and a
busybox.lrp (since they need upgrading often enough, and could
potentially be replaced by other things if someone wanted).
This makes me think: there is a binary included as a part of the
official ksh distribution, called ratz, which is basically tar+gunzip
wrapped into a single single-purpose package. Unlike ksh (which is
under the AT&T Open Source license) ratz is GPL, though I haven't been
able to find source.
So this is my thinking:
/linuxrc:
#!/bin/lua
...blah...
Included in root.lrp
/bin/lua
/bin/ratz
On disk, or elsewhere:
ash.lrp
busybox.lrp
busybox.lrp:
usr/local/bin/busybox
var/lib/lrpkg/busybox.list
var/lib/lrpkg/busybox.version
var/lib/lrpkg/busybox.sh
Then busybox.sh:
#!/bin/sh
export PATH=/bin:/sbin:/usr/bin:/usr/sbin
cd /usr/local/bin
./busybox cp ./busybox $(./busybox which busybox)
What this means is, that the root.lrp can be even smaller - but with
several penalties, if the single disk requirement remains:
* libc, ash, and busybox are still on disk, though now in independent
*.lrp packages
* a few binaries will grow, when they become statically linked
* a whole new language is added, possibly at the cost of adding 100k to
the needed space
One could also examine all of the binaries used for loading, and remove
all unused C libraries; this could remove some items from root.lrp,
making root.lrp smaller. If one can remove ALL C libraries, it means
the system is again much more upgradable, as it only needs to have the
libc.lrp replaced with the new one.
Imagine a boot disk where ash, busybox, or libc could be upgraded with
very little effort.... just copy in a new one and run.
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
