mdev

[Vladimir Dronnikov]

>
> Dunno.  How does the hotplug event for them come in when you echo "/sbin/mdev"
>> /proc/sys/kernel/hotplug ?  (Possibly it's a different directory?)

The fun is that I have no chance to echo "..." >/proc...
When kernel enumerates devices, there is yet no /sbin/mdev (root fs is
not yet mounted). And when I have mounted root fs and run "mdev -s",
the latter does not issue any hotplug event -- it just enumerates
/sys/class/*/dev. See the pitfall? "mdev -s" should really be
something like:
# echo -n "add" >/sys/{class,devices}/*/uevent

and "mdev without -s" should be renamed to "hotplug" and just be
hotplug helper. Only that way we'll reach consistency, IMHO. No matter
execution time. Consistency here is the corner stone.

>
> Note that mdev can only work with the information the kernel provides.  ISA
> pnp is legacy enough nobody may ever have bothered to hook it up to anything,
> (Its job was to autodetect I/O port, IRQ, and DMA ranges for ISA devices from
> 20 years ago.  This really doesn't come up much anymore.)
>
> Also, I was unaware that the pc speaker normally had a /dev node?  (You beep
> it via some ioctl on /dev/console or similar?  Mostly I just rmmod pcspkr to
> get it to _shut_up_.)
>

The speaker have no device, right. But it requires kernel module to be
working. This is done (in udev) by using the rule: if action is "add"
and $MODALIAS is set, then do "modprobe -q $MODALIAS". That way they
probe devices that need drivers. With current mdev, I never get
pcspkr.ko loaded, nor have I working serial ports (8250*.ko). Just
because mdev doesn't scan /sys/devices, and does not respect
$MODALIAS.

I've prepared the patch for mdev to fix the said issues. Please, take
a look and make comments.

Regards,
--
Vladimir
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mdev.patch
Type: application/octet-stream
Size: 3309 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20090414/b35040d8/attachment.obj>