jcnelson
commented
9 years ago Hi Somasis,
Apologies for the late reply. I was travelling for the last few days.
I'm a core developer for the Exherbo Linux distribution, and I've been putting some work into making the system run well without systemd, namely packaging things such as ConsoleKit2 and eudev.
Nice to meet you, and thank you for your interest in vdev!
vdev sounds very interesting, and the ISC license option is very appealing to me, as an advocate of permissively licensed software.
Regarding licensing, I should point out that vdev contains some code that is licensed as LGPLv2 and GPLv2. Specifically, the files under libudev-compat/ are licensed under the LGPLv2 because most of them are derived from libudev, and the files matching the shell glob vdevd/helpers/LINUX/stat_*.c are licensed under GPLv2 because they are derived from udev.
However, all other code is dual-licensed as GPLv3+ and ISC.
So, to get to the point, I'm wondering what the goals of vdev are, what the intended audience is, and what the standard usage of vdev, in simple terms really is.
There are three closely-related software suites that make up the vdev project, and they each have different goals.
First, there's vdevd (code is in vdevd/ and libvdev/, hardware database is in hwdb/, and recommended configuration, initscript, and initramfs scripts are in example/). When used with its recommended configuration, vdevd's goal is to be a udev work-alike. Specifically, vdevd generates a /dev tree equivalent to the one generated by udev, sets persistent network interface names, and generates enough of the /run/udev/ tree for udev client programs to continue working without modification.
Second, there's libudev-compat (code is in libudev-compat/). Libudev-compat's goals are two-fold. First, it strives to be an API- and ABI-compatible replacement for libudev, but without requiring a device manager to be installed (i.e. instead of opening a netlink socket to udev, it watches a directory into which some other program will put device events encoded as text files). This is by far the most common use-case. Its other goal is to allow the admin to manipulate and namespace device event queues on a per-process basis. This is specifically meant to help libudev-dependent programs run in containers without needing a device manager or direct access to /dev--the user can simply link the container's device event directory into a canonical place in the root context where device events will get written.
Third, there's vdevfs (whose code is under fs/). You probably don't need vdevfs if all you need is a udev/libudev replacement. Its goal is to enforce a per-process view of /dev, by allowing the admin to control which device files and inode metadata a given process will "see" on stat(2) and readdir(3). With the proper configuration and scripts (HUGE weasel words right there), an admin can use vdevfs to do ConsoleKit-like and logind-like things. For example, vdevfs can be configured to ensure that every process in an inactive session cannot open video, audio, and input devices (simply by omitting them on readdir(3)). As another example, vdevfs can be configured to ensure that a process in one seat can only access hardware belonging to that seat (simply by ensuring that all other device files appear to have mode 000). Importantly, it can do these things regardless of the process's pid, (e)uid and (e)gid (the process identification criteria themselves are defined in the configuration), and processes do not need to be vdevfs-aware and do not need a client library. However, the devil is in the configuration details--I still need to work out a good set of recommended configuration files and helper programs to get vdevfs to provide equivalent functionality.
Regarding the intended audience, the vdev project is targeted towards an even larger group of users than (e)udev. It not only replaces udev and libudev for day-to-day desktop usage (there are early adopters in the Devuan community who have already switched), but also works with musl-based distros and statically-linked distros. I would like it to compile with the LLVM/Clang toolchain at some point, as well as port it to OpenBSD and other UNIXes that don't have a dynamic /dev. I'm also gearing it towards working in container-centric environments, where contained processes need fine-grained access to device files and events (which udev does not handle well).
Is it meant to replace udev and ConsoleKit2's functionality, or just udev? Will the configuration syntax be the same? Is it going to be easy to replace udev?
Vdevd is meant to be a drop-in replacement for udev, and libudev-compat is meant to be a drop-in replacement for libudev. Udev- and libudev-dependent programs do not need to be modified to use vdevd and libudev-compat (if they do, it's a bug in the vdev project).
However, the configuration syntax is not the same. Vdevd is a lot like mdev or nldev, if you're familiar with them--you define a rule to match a device event (e.g. by name, by subsystem, etc.), and supply a helper program to run when vdevd receives a device event that matches it. Vdev's default set of rules (called "actions", under example/actions/), helper programs, and scripts cause vdevd to generate /dev and /run/udev, and to write device event files for libudev-compat clients to consume. There is some early work on making a udev-rules-to-vdev-action-and-script compiler, but it is far from finished.
Regarding replacing udev, running "make && sudo make install" will get you most of the way there. However, you'll need to disable udev, enable vdev, and rebuild your initramfs to include vdev in order to have vdev take over. The hacky, Debian-specific way to do this is to run "cd example/ && make initramfs", which should generate an initramfs image in example/ that you can go on to install with your bootloader. If you're using sysvinit, you can run "cd example/ && make initscript-install", which (on Debian) should disable udev's initscript and enable vdev's. I'm still working on the packaging scripts that will do all of this automatically.
Hope this answers your questions!
somasis
Hi, I'm a core developer for the Exherbo Linux distribution, and I've been putting some work into making the system run well without systemd, namely packaging things such as ConsoleKit2 and eudev. I'm a little confused with some of the phrasing in the README, and I hope you could explain it to me.
As the current state stands, the packages most non-systemd systems need are ConsoleKit2, eudev, and which init system is desired. vdev sounds very interesting, and the ISC license option is very appealing to me, as an advocate of permissively licensed software.
So, to get to the point, I'm wondering what the goals of vdev are, what the intended audience is, and what the standard usage of vdev, in simple terms really is. Is it meant to replace udev and ConsoleKit2's functionality, or just udev? Will the configuration syntax be the same? Is it going to be easy to replace udev?
I'm very interested in this project from reading your blog post and README for this program and maintaining it for my distribution. I hope you'll be able to answer my questions. Thank you.