Hey everyone, After a longer-than-expected development cycle, I have the latest news for vdev.
The TL;DR is that vdev has gained enough infrastructure to generate the information that normally gets put in /run/udev. This is important for most libudev clients, because this information gets used to detect and enumerate hardware. It's the way the X server detects input devices via udev, for example. This is still being heavily tested, and is not complete, but I am please to report that: * vdev now tracks device properties and device tags, under /dev/metadata/$DEVPATH/properties and /dev/metadata/$DEVPATH/tags/, respectively. They are added by shell library subroutines available to vdev's helpers (in subr.sh). * vdev now uses the same hardware database as udev to report human-curated hardware properties (such as human-readable vendor strings). To keep things simple, vdev comes with a script that generates a squashfs filesystem image from the *.hwdb files installed to /lib/udev/hwdb.d and /etc/udev/hwdb.d. This is our alternative to systemd's/udevd's mmap()-able on-disk hwdb trie. The filesystem image itself gets mounted to /dev/metadata/hwdb by the pre-seed script, and vdev now comes with a helper tool (hwdb.sh) that can use a combination of a modalias string, a devpath, a subsystem path, and some sysfs information to look up the device properties. * vdev now comes with a "udev-compat.sh" helper script that reads vdev's /dev/metadata/ directory and hardware database in order to generate /dev/metadata/udev, which is meant to be symlinked to /run/udev. This lets the udev_enumerate API detect and enumerate devices by tags and properties. It is important to emphasize that this helper is logically isolated from the rest of vdev--vdev gets along just fine without it (since all udev-isms are contained by this helper), so if you don't need /run/udev, you can safely disable this helper script. * Disk property detection has been significantly improved, and is much closer to how udev does it (including adding support for querying a disk's parent device's properties, which is necessary to handle partitions properly). Thanks to Didier for working with me on this! In time, it will also work the busybox tools, but I am still working on getting busybox's blkid to work here (specifically, we need the "-p" flag to work in order to get low-level partition table information and filesystem metadata). There is of course more work to be done on this, but the next big milestone (my next goal) will be to boot to X with vdevd, without having to generate an xorg.conf. I have not tried this yet, and I do not expect it to work as of the latest commit, but I believe that all the necessary infrastructure is in place to begin the painstaking process of ensuring that vdev detects enough of the host's devices' properties for commonly-used libudev clients work as they did with udev. This will confirm that we generate enough of /run/udev/ for alpha. Thanks, Jude
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
