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