The design of mdev (mini-udev for busybox).

[Ned Ludd]

On Sun, 2005-12-04 at 13:01 -0600, Rob Landley wrote:
> By the way, for those of you curious, the basic idea behind mdev is to do a 
> stripped down udev for busybox.  My TODO entry about this reads:
> 
>   mdev
>     Basic merge.
>     Config file
>       regex support
>       username:group (string, not just uid:gid)
>       zap cmp
>       local_errno
>       bb_xasprintf();
>       add dir/
>       add shellout
>     syntaxes:
>       symlink -> symlink
>       dir/ (and dir| dir=)
>       thing uid:gid 777
>       /dev/initctl - a named pipe?
>     Is the "" escaping useful here?  (Spaces?)
> 
> And translating that for everybody else:
> 
> I have some existing C code (a simple C port of the shell script posted last 
> message).  The "zap cmp, local_errno, bb_xasprintf()" bits are just about 
> that code being busyboxified.
> 
> There are two modes for mdev.  One scans /sys and creates devices for 
> everything it finds.  (That'll be "mdev -s".)  The second is called from 
> hotplug and looks at the environment variables to see what new device just 
> cropped up/went away, and adds or removes it.  (That's mdev with no 
> arguments.)  Both need to wash its action through the config file.
> 
> Why a config file?  Because we have to specify ownership and permissions on 
> newly created devices.  The config file needs to be as sparse as possible and 
> easy to parse with a small amount of code, but we do need one. 
> 
> A basic device entry looks like:
> devname uid:gid permissions
> 
> So for example:
> tty3 0:0 600
> 
> It dumps everything in the same directory (no devfs-style loop/0 nonsense), 
> and works based on the names the kernel gives stuff.  The goal here is to be 
> _simple_.  It'll need some kind of regex support to allow a single rule to 
> match tty[0-9]* or hd[a-z][0-9]*.  For each device, rules are scanned top to 
> bottom and we stop at the first hit, so you can specify a tty3 and then a 
> default tty[0-9]*.
> 
> This is the minimum we need.  Anything beyond this should be a CONFIG_FEATURE.
> 
> If we're feeling posh, we should look up UID:GID in /etc/passwd and /etc/group 
> so we can use names rather than just numbers.  That's probably a configurable 
> feature.
> 
> Since mdev will generally be run on an empty tmpfs (and may in fact mount 
> tmpfs itself), we may also need to create a few directories (pts, shm) and 
> named pipes (initctl) and such in there.  The config file can specify these 
> things (with ownership and permission) by appending the characters from "ls 
> -F".  For example:
> 
> shm/ 0:0 1777  # Yes, setting the sticky bit needs to be supported.
> initctl| 0:0 600
> 
> And for symlinks, we use " -> " again just like ls does, so:
> cdrom -> hdc
> 
> Non-device lines like these would only be matched on the initial scan (-s), 
> not when looking for a description of a new device.  And that's a second 
> configurable feature: the user could also mount tmpfs from a shell script and 
> do that setup before calling "mdev -s".  It is nice to have it all together 
> in one config file, though.
> 
> In future we might also need a shellout syntax, and I suggest:
> 
> hdc 0:24 660 $/etc/mdev/mkhdc.sh # create symlink, call dbus, etc.
> pts/ 0:0 755 $mount -t devpts /dev/pts /dev/pts
> 
> It'll automatically inherit all those nifty environment variables.  (We can 
> synthesize one: MDEV_SYSFS which is the path to the sysfs entry we're 
> servicing.  That way the cold boot scanning case can cope.)
> 
> Ordinarily we don't distinguish between char and block devices, but if a need 
> to do this does crop up I suppose could always append @b or @c, so for 
> example a catch-all rule for otherwise unspecified block devices could be:
> .*@b 0:0 600
> 
> Anyway, this is what I'm thinking about.  Comments?

I think you just about covered the needs of what mdev should do and how
it should function. But then you already know I'm a fan :)

-- 
Ned Ludd <solar at gentoo.org>
Gentoo Linux