Hey everyone,
In keeping with the request to give more frequent status updates on
development, here's where things stand now with vdev.
=== CURRENT STATUS ===
I consider vdev closer to being done than closer to having been just
started, and it's mature enough that early testers can start experimenting
with using it to boot Devuan in a VM (maybe even on real hardware, if
you're the adventurous type). Not only does it create all device files in
/dev that you'd expect, but also it set up and maintains the directories
and symlinks for:
* /dev/block
* /dev/char
* /dev/bus
* /dev/bsg
* /dev/cpu
* /dev/disk/by-id
* /dev/disk/by-uuid
* /dev/dri
* /dev/cdrom, /dev/cdrw, /dev/dvd, /dev/dvdrw
* /dev/input/by-path
* /dev/mapper
* /dev/net
* /dev/rtc
* /dev/snd/by-path
* /dev/v4l
Unlike udev, the logic to handle the aforementioned files is handled by
simple shell scripts and ini files. To keep things simple, vdevd only
knows how to (1) probe sysfs and listen for device events, (2) match device
events to vdev "actions", (3) mknod or unlink the device file proper, and
(4) execute shell scripts which go on to rename or set up the device files
and symlinks, using data passed in from the kernel via vdev as environment
variables. I've taken the liberty of providing a set of shell scripts, a
shell library, and utility programs that will cause vdev to set up your
/dev/ in a manner as close to how udev does it as possible (in fact, a lot
of code in said utility programs is imported from udev, but stripped of
their libudev dependencies).
=== TEASER ===
Getting vdevd to take device-specific actions is very straightforward if
you're familiar with basic shell scripting. The utility programs and shell
library handle the intricacies of probing for device drivers, subsystems,
and capabilities, as well as managing per-device metadata and tracking
per-device symlinks. All that remains is to put device files and symlinks
in the right places.
As an example, here's how you'd get vdevd to set up the symlinks in
/dev/char:
(1) Create a vdev "action" file that tells vdev to run a script whenever it
adds or removes a character device:
$ cat example/actions/char.act
[vdev-action]
event=any
type=char
command=exec $VDEV_HELPERS/char.sh
(The line on the "command=" directive gets fed directly into /bin/sh;
$VDEV_HELPERS is the path to the directory holding shell scripts and
programs to set up devices, akin to /lib/udev).
(2) Create a script to implement the action:
$ cat vdevd/helpers/LINUX/char.sh
#!/bin/sh
. $VDEV_HELPERS/subr.sh
case "$VDEV_ACTION" in
add)
add_link ../$VDEV_PATH $VDEV_MOUNTPOINT/char/$VDEV_MAJOR:$VDEV_MINOR
$VDEV_METADATA
;;
remove)
remove_links $VDEV_METADATA
;;
*)
fail 1 "Unknown action '$VDEV_ACTION'"
;;
esac
exit 0
(All variables prefixed with VDEV_ are passed to the script via vdevd.
"add_link" and "remove_links" are subroutines from $VDEV_HELPERS/subr.sh
that let you keep track of which symlinks you created for a device).
In addition to simplifying device setup/shutdown, vdev preserves the
information that you'd normally get from "udevadm info" under a directory
tree in /dev/vdev. Within this directory are directories for each device
file, and in each of these directories are a set of files that correspond
to uevent variables passed to vdev from the kernel as well as any runtime
metadata created by the utility shell library (i.e. listing of symlinks).
For example:
$ ls dev/sda # my hard drive
dev/sda
$ ls dev/vdev/sda/ # dev/sda's metadata
DEVNAME
DEVPATH
DEVTYPH
links
SUBSYSTEM
SYSFS_MOUNTPOINT
$ cat dev/vdev/sda/DEVPATH # dev/sda's sysfs devices path
/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda
=== TODO ===
There's still a few major shortcomings before I'm comfortable tagging an
alpha release, which I list below:
* vdevd needs an accompanying init script to mount devtmpfs and set up:
-- /dev/stdout
-- /dev/stderr
-- /dev/stdin
-- /dev/core
-- /dev/shm
-- /dev/MAKEDEV
-- /dev/fd
-- /dev/log
-- /dev/xconsole
-- and probably others
* There are no scripts yet to handle /dev/input/by-id and /dev/vboxusb, and
probably others that I haven't encountered since I've thus far only tested
it on my laptop.
* There is no man page yet. I'll make some wiki pages at some point which
hopefully will become man pages.
* vdevd only partially supports "run-once" semantics. The idea is that
users who don't need vdevd to be running all the time can instead run it
periodically or manually to have it populate and repopulate /dev with
device files for currently-installed hardware. vdevd populates /dev, but
it does not yet remove files from between invocations (although it keeps
track of the necessary data to do so under /dev/vdev).
* vdevfs, the per-process device access control filesystem that can
optionally overlay /dev and hide device files from unprivileged processes
(for an admin-defined (!!) definition of "unprivileged"), does not yet
support regular files. This will be necessary for vdevd to populate
/dev/vdev.
* probably other bugs that we'll discover down the road...
That's all for now. The project page is here, if you're interested in
trying vdev out: https://github.com/jcnelson/vdev
-Jude
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
