[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:

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:
> 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.


More information about the Aboriginal mailing list