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
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
