RFD: Rework/extending functionality of mdev

[Harald Becker]

Hi,

I'm currently in the phase of thinking about extending the functionality 
of mdev. As here are the experts working with this kind of software, I 
like to here your ideas before I start hacking the code.

I like to focus on the following topics:


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.

I like to extend the syntax of mdev.conf with some extra information and 
add code into mdev to allow to do this operation in a more simplified 
way, but still under full control of the system maintainer. Those extra 
entries will only be executed whith "mdev -s" not during hotplug. The 
syntax has been chosen to not (horribly) break existing mdev.conf setups.

Current major syntax of mdev.conf:

[-][envmatch]<device regex> <uid>:<gid> <permissions> [...]
[envmatch]@<maj[,min1[-min2]]> <uid>:<gid> <permissions> [...]
$envvar=<regex> <uid>:<gid> <permissions> [...]

- Additional syntax to mount (virtual) file systems:

MOUNTPOINT  UID:GID  PERMISSIONS  %FSTYPE [=DEVICE] [OPTIONS]

This rule is triggered by the percent sign indicating the file system type.

This shall create the mount point (if it not exist), set 
owner/group/permissions of the mount point, fork and exec "mount -t 
FSTYPE -o OPTIONS DEVICE MOUNTPOINT".  If DEVICE is not specified the 
literal "virtual" shall be used.

e.g.

# mount virtual file systems
/proc      root:root 0755 %proc
/sys        root:root 0755 %sysfs
/dev       root:root 0755 %tmpfs size=64k,mode=0755
/dev/pts root:root 0755 %devpts

This will do all the required mounting with a single "mdev -s" 
invocation, even on a system which has nothing else mounted. The old 
behavior to mount the file systems in the calling scripts will still be 
available, just leave out the mount lines from mdev.conf.

- Additional Syntax to add directories and set there owner informations:

DIRNAME/  UID:GID  PERMISSIONS [> LINKNAME]

This rule is triggered by the slash as the last character of the match 
string. It shall create the given directory, where relative names are 
from the expected /dev base.

e.g.

# add required subdirectories to the device file system
loop/   root:root 0755
input/  root:root 0755

Those directories may be created automatically due to other rules, but 
then you can't control there owner informations. The extra rule allows 
to create the subdirectories on startup and set the owner information as 
you like. Later matching device rules will not change this, so you can 
tune the directory and device permissions.

- Additional syntax to add symlinks and set there owner information:

PATHNAME@  UID:GID   > LINKNAME

This rule is triggerd by the at sign as last character of the match 
string. Shall add the given PATHNAME as a symlink to LINKNAME, and set 
the owner of the link.

e.g.

# add symbolic links to the device filesystem
fd@      root:root  >/proc/fd
stdin@   root:root  >fd/0
stdout@  root:root  >fd/1
stderr@  root:root  >fd/2

- Extending syntax for symlink handling on device nodes:

The current syntax allows to either move the device to a different 
name/location or to move and add a symlink. In some situations you need 
just a symlink pointing to the new device.

DEVICE_REGEX  UID:GID  PERMISSIONS  =NEW_NAME
(old) Moves the new device node to the given location.

DEVICE_REGEX  UID:GID  PERMISSIONS  >PATHNAME
(old) Will create the new device node with the name PATHNAME and create 
a symlink with DEVICE_NAME pointing to PATHNAME. Shall remove existing 
symlink and create a new one.

DEVICE_REGEX  UID:GID  PERMISSIONS  <PATHNAME
(new) Shall create the new device under it's expected device name, and 
in addition create a symlink of name PATHNAME pointing to the new 
device. Existing symlinks shall not be touched.

e.g. creating a /dev/cdrom symlink for the first cdrom drive

sr[0-9]+  root:cdrom  0775  <cdrom
Shall create /dev/sr0 and a symlink /dev/cdrom -> /dev/sr0, but will not 
overwrite the symlink for /dev/sr1, etc.

This may be combined with the move option:

DEVICE_REGEX  UID:GID  PERMISSIONS  =NEW_NAME  <PATHNAME
Shall move the device to NEW_NAME as expected and then create the 
symlink to that location.

e.g. moving sr0 into subdirectory and adding symlink

sr[0-9]+  root:cdrom  0775  =block/  <cdrom
Shall create /dev/block/sr0 and a symlink /dev/cdrom -> /dev/block/sr0, 
not changing /dev/cdrom if it already exists.


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. 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). When 
there are no more events for more then a few seconds, the first instance 
closes the pipe and the second instance exits (freeing the used memory). 
On next hotplug event a new pipe / second instance is created.


The primary intention is, to get the complete device/base system setup 
by just doing a single call to mdev. All controlled by the configuration 
file /etc/mdev.conf giving the rules to setup the system.

Any comments on those are really welcome. I like to get those features 
usable by as many people as possible, and like to hear if those changes 
are welcome.

--
Harald