[Aboriginal] Replacing bash with mksh
Isaac
idunham at lavabit.com
Tue Jun 11 23:24:42 PDT 2013
On Mon, Jun 10, 2013 at 08:51:07PM -0700, aboriginal-request at lists.landley.net wrote:
> From: Rob Landley <rob at landley.net>
> On 06/10/2013 02:33:06 AM, idunham at lavabit.com wrote:
> > On Sat, Jun 08, 2013 at 02:00:49AM -0500, Rob Landley wrote:
> > So there are now four versions of mount floating around, none of which
> > are publicly available?
>
> I think a couple got posted to the mailing list? (People keep emailing
> me off list. Dunno why. The most recent is attached, the previous one
> was... october I think?)
Ah, it was before I subscribed.
> Plus klibc has one, android toolbox has one...
> Last time I sat down to write mount, it used loopback stuff first so I
> had to write a proper losetup (which I did, although that had grown a
> lot of new features since last I'd checked). Then I started researching
> all the new mount flags, and I have a stub that can enumerate them and
> print out help text for them (also attached). The "actually does
> something useful" variant trails off in the middle and does not
> currently compile...
Also there's this one:
http://lists.landley.net/pipermail/toybox-landley.net/2012-November/000691.html
Which is not a full mount, by any stretch of the imagination.
> Also, keep in mind that I did several months digging into the guts of
> NFS back in 2010 and would like to use the new string interface instead
> of the old binary interface:
>
> http://landley.livejournal.com/52663.html
>
> Basically all the "smbmount" and "nfsmount" and such front-ends are
> doing three things:
<sniP>
> I.E. if you know what you're doing you can do an NFS or samba mount
> from a mount command that doesn't know anything special about that
> filesystem. (But if the command DOES know about it, it can intercept
> what you actually said and screw it up.)
>
> Having large amounts of extra code for this is silly...
Which is ~ 1/2 or more of the large version...
> > > Plus I still have a todo list of commands to triage that predate
> > > "pending" (vmstat, login, du, vconfig, mountpoint, free, chroot,
> > > cut, touch modinfo, expand) and some of them have shrapnel in
> > > lib/lib.c (for example "cut" added get_int_value() which is
> > > something lib/args.c already does...)
> > >
> > modinfo seems to be good for uncompressed modules afaict.
>
> Needing to triage doesn't mean they don't work. The ifconfig command
> worked before I started triaging it, it was just twice the size of the
> current one (and I'm not done yet).
> > I'd write a test for it if I could figure out how to do one that
> > works with
> > all Linux hosts...but the corner cases it makes sense to check may
> > not be
> > present on many systems.
>
> I don't understand. Care to explain?
The tests that could be done would depend on having certain uncompressed
modules (since we don't yet support compressed modules...) present to check
results against.
*Not every system even has kernel modules present/supports modules
*Anything that can be a module can be disabled
*It's possible to disable anything that uses firmware.
Of course now that I'm writing this I test and see that multiple modules
should be supported, but aren't; expect a test and a patch sometime soon.
As far as supporting compressed modules goes...
It could probably be done via a hook in lib/*.c (xdecompress?) which will
-use magic numbers (NOT extensions, we may want support for autodetecting
file format of streams for tar...) to identify the format <A>
(about 6 bytes should be enough:
BZh bzip2,
{ 0xFD, '7', 'z', 'X', 'Z', 0x00 } xz,
1F 8B 08 gz,
..)
-fork <A>cat with the file/stream as input and the toy then reads the
output stream
> > (Coincidentally, toybox modinfo does the right
> > thing for "modinfo oss-usb" where busybox fails; oss_usb.ko is the
> > file
> > name, it's part of the out-of-tree OSS4 code...)
>
> If I recall, modinfo doesn't parse the elf tables but just does a
> string search of the binary. I'm not sure I'd call that "the right
> thing", it seems extrordinarily brittle to me.)
Ah, I see.
> > Examples of test cases:
> > modinfo a-module -> a_module.ko
> > modinfo a_module -> a-module.ko
> > modinfo radeon
> > (mile long list of firmware that changes with each kernel version
> > follows)
>
> I'm always happy to fluff out the test suite, if you'd like to send a
> patch. :)
>
> > > I grabbed the original massively stale version from 1999, on the
> > > theory there's probably less of it to read. "wc -l *.c" says the
> > > total is 27180 lines, which is a couple solid days triaging right
> > > there.
> >
> > 23460 for ksh-openbsd, patches applied.
> > So someone has achieved negative code growth.
>
> Yay?
>
> Is it still public domain?
Yes, except for alloc.c, mknod.c, and strl{cpy,cat}.c, which are 3-clause
(or less) BSD, and posix_signals.h, which apparently is still 4-clause BSD.
Of those, alloc.c is the only one that would be relevant.
1371018282.0
More information about the Aboriginal
mailing list