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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
