Hi Harald !
1) Starting up a system with mdev usually involves the same steps to mount proc, sys and a tmpfs on dev, then adding some subdirectories to /dev, setting owner, group and permissions, symlinking some entries and possibly mounting more virtual file systems. This work need to be done by the controlling startup script, so we reinvent the wheel in every system setup.
The thing is, this work doesn't always need to be done, and when it does, it does whether you use udevd, mdev, or anything else. /dev preparation is one of the possible building blocks of an init routine, and it's quite separate from mounting /proc and /sys, and it's also separate from populating /dev with mdev -s. So I'd say that it's not about reinventing the wheel, it's that every system has different needs - and a 10-line script is easy enough to copy if you have several systems with the same needs. I dislike the idea of integrating early init functions into mdev, because those functions are geographically (as in the place where they're performed) close to mdev, but they have nothing to do with mdev logically.
- Additional syntax to mount (virtual) file systems: MOUNTPOINT UID:GID PERMISSIONS %FSTYPE [=DEVICE] [OPTIONS]
I can't help but think this somehow duplicates the work of mount with /etc/fstab. If you really want to integrate the functionality in some binary instead of scripting it, I think the right way would be to patch the mount applet so it accepts any file (instead of hardcoding /etc/fstab), so you could have a "early mount points" file, distinct from your /etc/fstab, that you would call mount on before running mdev -s.
2) I like to use netlink to obtain hotplug information and avoid massive respawning of mdev as hotplug helper when several events arrive quickly. That is, I want to auto fork a daemon which just open the netlink socket.
So far, what you're talking about already exists: http://skarnet.org/software/s6-linux-utils/s6-devd.html
When events arrive it forks again, creating a pipe. The new instance read mdev.conf, build a table of rules in memory, then read hotplug operations from the pipe (send by the first instance).
... but here it's different. s6-devd spawns a helper program for every event, like /proc/sys/kernel/hotplug would do, but it reads the events from the netlink so they're serialized. In your design, the long-lived process forks a unique helper that reads mdev.conf... so it's not meant to be used with any program compatible with /proc/sys/kernel/hotplug - it's only meant to be used with mdev. So, why fork at all ? Your temporary instance is unnecessary - just have a daemon that parses mdev.conf, then listens to the netlink, and handles the events itself. ... and you just reinvented udevd. Congratulations ! ;) Seriously, udev is a hard problem. udevd is bloated and its configuration is too complex; mdev is close to the point where parsing a config file for every invocation will become too expensive - I believe that it has not reached that point yet, but if you add more stuff to the conf language, it will. What we need is a configuration language for udev that's easy to understand (for a human) and fast to parse (for a machine). More thought needs to be poured into it - and it's in my plans, but not for the short term. What I'm sure of, though, is that the "fork a helper for every event" vs. "handle events in a unique long-lived program" debate is the wrong one - it's an implementation detail, that can be solved *after* proper udev language design. -- Laurent _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox