I was weak!
rob at landley.net
Tue Dec 13 08:43:34 UTC 2005
I know I said "no new features after -rc2", but I'd like to point out that
-rc2 hasn't shipped yet.
The first part of mdev is in, it's under util-linux. It has a CONFIG entry
for /etc/mdev.conf but there's no actual code yet. (Nor does it handle
hotplug mode, despite what the config entry and help says. Just "mdev -s"
right now. That, however, I tested, and it worked for me. You have to
setup /sys and /tmp before calling it, and all that creating files and
directories stuff turns out to probably be a bad idea.)
Yes, "/dev" and "/sys" are hardwired in. I don't currently care.
I'll probably take a stab at implementing the config file stuff tomorrow.
It's not big, I'm just tired (and _should_ spend more time on the bug list
tonight). I've got the config entry and documentation for it already, and
there are some comments showing where the code itself goes...
For hotplug, I think the exec mode should be plenty. I don't think we need
netlink and a daemon mode. Your average shell script can exec hundreds of
times per second (even on a fairly slow embedded system), and if that isn't
fast enough, you can always use Greg KH's version. (And the initial populate
isn't done via hotplug but via scanning /sys anyway: you enable hotplug
functionality after you do that to handle _additional_ devices showing up, by
writing to the relevant /proc entry, which the help mentions.)
The least racy way to do this seems to be:
A) flush any boot time hotplug events (just ignore 'em; not quite sure how to
do this but I suspect there's a way).
B) call mdev -s to scan for all the directories flushed in step A. (This is
currently more or less instantaneous.
C) Point /sbin/hotplug at mdev to handle new events. (No, not via symlink:
you have to call it under the name mdev for busybox to know what to do, which
requires diddling /proc. I can add "hotplug" as a synonym, I suppose, but
it's not high priority here.)
Assuming new hotplug events queue up between steps A and C, nothing gets lost.
(We might get some duplicate events, but that shouldn't cause a problem.)
If they don't queue up, then swap C and B. The only potential race I see from
_that_ is if a device is unplugged while mdev doing its scan, then in theory
mdev -s could find a device in /sys after the hotplug remove event is
generated for it, so the scheduler could let the hotplug remove complete
before mdev -s generates the device. I'm not sure this is actually possible,
though. It's definitely not enough of a real world concern for me to really
care about. (Devices shouldn't be removed during boot, which is the only
time scanning is happening. The window is tiny if it exists at all, and the
race would tend to favor the correct order: mdev has to successfully read the
major:minor data out of the sysfs entry or it won't go on to do the mknod,
and scheduling away between that and the mknod is fairly unlikely. In any
case, the potential downside is just a leftover /dev entry for a device we no
longer have anyway. Cry me a river.)
I'll play with it more later. In theory, many embedded devices are unlikely
to care about the hotplug aspects at all, they _just_ want "mdev -s". But
they will want the config file to control ownership and permissions. :)
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
More information about the busybox