[Aboriginal] Busybox applets not yet implemented

[idunham at lavabit.com]

On Sat, May 18, 2013 at 01:02:56AM -0500, Rob Landley wrote:
> Cleaning out my drafts folder, I have this:
> 
> On 04/19/2013 01:36:23 AM, idunham at lavabit.com wrote:
> >Landley wrote:
> >My own experiments with booting a Debian system with a custom
> >shell init
> >indicate that only a few things are needed to boot up a system
> >properly:
> >-a sh: pd/mksh is enough for now.
> 
> I have a lot of design work done for toysh. Wack-a-moleing my way to
> it...
> 
> >-mount: the next most important part.
> 
> That's fairly high on my list, I just keep getting toys/pending/*
> files I need to clean up before doing new stuff...
 
> >-mdev: fixing /dev does demand some subdirs, and hotplug will require
> >handling env variables (which busybox has support for);
> >not highest priority, though.
> 
> Question: how much does devtmpfs handle (there was a recent thread
> on busybox about an environment variable they weren't using listing
> subdirectories)

I'll have to reboot and check that...Ok, very little.
These are all the subdirs in /dev when devtmpfs is the only tool used
but all modules are loaded:

/dev/bus/usb
/dev/bus/usb/005
/dev/bus/usb/005/003
/dev/bus/usb/005/002
/dev/bus/usb/005/001
/dev/bus/usb/004
/dev/bus/usb/004/001
/dev/bus/usb/003
/dev/bus/usb/003/001
/dev/bus/usb/002
/dev/bus/usb/002/001
/dev/bus/usb/001
/dev/bus/usb/001/001
/dev/dri/card0
/dev/dri/controlD64
/dev/bsg/0:0:0:0
/dev/input/mouse1
/dev/input/mouse0
/dev/input/mice
/dev/cpu/1
/dev/cpu/1/cpuid
/dev/cpu/1/msr
/dev/cpu/0
/dev/cpu/0/cpuid
/dev/cpu/0/msr

Note that I use OSS4, so the sound subsystem is not typical.

DEVNAME can include any number of subdirs, so be aware of that.
And the issue was that busybox was not getting $DEVNAME on coldplug
(mdev -s); the solution was to open the proper uevent file and read 
DEVNAME from there.

> >-grep, modprobe, cut: I autoload modules by
grep -h MODALIAS /sys/bus/*/devices/*/uevent 2>/dev/null |cut -d = -f 2|xargs modprobe -abq
> 
> Should there be a tool that does this? (An mdev flag, perhaps?)

That's possible, but I tend to think that something I can do in 92
characters and one line of shell is not a justification for a new
feature--features that are that duplicative of standard tools sound like
a GNU project. ;-)
(Admittedly, grep -h is not POSIX.  But you'll need it for the kernel
build.)

Also, if you do add an mdev flag, it should be something that you can
run separately from seeding /dev; autoload MUST take place AFTER
manually loading modules, or you complicate things like loading Linux-PHC
modules (where an out-of-tree module provides a needed hook for an
in-tree module or builtin). I've fought with this a good bit. 

> >modprobe needs the following for this use case:
> >Support aliases. May require depmod.
> >-a: insert all modules in a list at once
> >-b: blacklist needs to work!
> >-q: Hot/coldplug shouldn't spit out a mile of errors.
> 
> Um, blacklist? (Explain? Why is this needed, and the man page says
> there's a config file...?)

-b turns on respecting the blacklist config file.
The default is "ignore blacklists"; this is reasonable because you will
sometimes want to test what happens, and you usually have a reason for
loading a kernel module manually.  In other words, assume the user knows
what they're doing.
But if you autoload modules, you will run into the situation where some
module that's autoloaded crashes the computer, or messes up the sound
(look at /etc/modprobe.d/alsa-base-blacklist.conf), or something of like
sort. It may be a bug, but it happens, and nothing is more annoying than
a bug you know the cause of but don't have the tools to workaround.

So there are two real options:
1. Assume the administrator knows what he's doing, and load anything
unless you tell modprobe to be careful.  Scripts can use modprobe -b and
the admin can use modprobe.
2. Assume that whoever wrote the blacklist usually knows better than the 
admin. Don't load blacklisted modules unless the admin forces it, with 
modprobe -f; scripts can just use modprobe.

Option 2  optimizes for shorter scripts at the expense of longer command 
lines and more troubleshooting.

Option 1 is what standard modprobe uses.

The config "file" for blacklisting is /etc/modprobe.d/*.conf, formerly
/etc/modprobe.conf.
/etc/modules has stuff to autoload.

HTH,
Isaac Dunham


 1368948149.0