I was weak!

Rob Landley 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. :)

Rob
-- 
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 mailing list