Hey everyone,

I have the latest news on vdev over the past two weeks. I'm not sure if
the news from last week made it to the mailing list; apologies if the
latter half of this email is redundant.

[Week of March 15]

This week, the Linux port of vdev is now accesses /sys in a manner that is
fully consistent with the rules set forth here:
https://www.kernel.org/doc/Documentation/sysfs-rules.txt. This closes
issue #14.

In addition, vdev gained a helper script that uses a very simple config
file (a lot like /etc/mactab or /etc/iftab) to support persistent network
interface names. The config file takes the form of lines that are either
comments (prefixed with '#'), or the form of "IFNAME mac|devpath MATCH",
where IFNAME is the persistent interface name and MATCH is either the MAC
address if "mac" is given, or the sysfs device path if "devpath" is given.
An example config file for a USB dongle is given in example/ifname.conf.

Testing vdev on vagrant is still a work in progress.

[Week of March 8]

This week, the Linux port of vdev has gained something no other device
manager supports: the ability to patch /dev. Patching /dev combines the
best of MAKEDEV and dynamic /dev in that it on invocation, vdev will only
add and remove device files for hardware that added or removed since the
last patching. It will run device-add and device-remove actions as usual,
so things custom device symlinks will continue to get installed as
expected. This feature can be accessed by running "vdevd --once". Thanks
to Aldemir Akpinar for the suggestion!

In addition, vdevfs (the filesystem half of vdev) can now be built,
installed, and run fully independently of vdevd, or any agent that manages
/dev (udev, mdev, static /dev). Users can mount it on top of /dev at any
time, and while running, vdevfs will selectively hide device files from
unprivileged processes according to its ACL rules. Vdevfs is an optional
component of vdev--vdevd does not need it, nor is it even aware of its
existence.

[Misc]

I have an idea I wanted to field to the Devuan community for implementing a
dbus-free, polkit-free, X11-free, and systemd-free replacement for
udisks2. If you've taken a look at vdev's source code, you'll see that it
supports multiple different device event backends (in order to make it
portable). What I'm considering doing is creating vdevd-user, a build of
vdevd with a backend for watching the contents of /dev, instead of
listening to the kernel for device events.

Unlike vdevd, vdevd-user could be run by unprivileged users independently
of whatever manages /dev, and would run user-specific device-add and
device-remove commands with the user's privileges. Otherwise, it would
behave exactly like vdevd--it supports the same config files, action
definitions, and shell utilities. For example, if /dev/sdb1 appeared in
/dev, vdevd-user would notice it and run a shell script to pmount it,
create a .desktop file for it in the user's Desktop directory, and open a
file manager to it on the user's X11 screen. If /dev/sdb1 disappeard,
vdevd-user would pumount it if it was still mounted (hopefully it was not!)
and remove the .desktop file.

Thoughts?

-Jude