RFD: Rework/extending functionality of mdev

[Laurent Bercot]

  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