On 25/06/15 17:04, Jude Nelson wrote:
> 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

That's awesome new Jude. Thanks to you and all who have been
participating on this project.

Regards,
--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722