Hi Jim,


> It seems udev is getting split up between several projects within systemd
> and GNOME. It seems gudev is being handed off in the future to GNOME and
> parts of udev are being pushed deeper into systemd.
>
>
gudev splitting off isn't a problem; in fact, I applaud the decision.


> I'm not surprised at this, since kdbus didn't get pushed into the kernel
> mainline, but it does show evidence of the callousness being presented to
> the Linux ecosystem. If they don't get their way one way, they try to get
> their way another.
>
> I am wondering how much longer eudev can remain tied to systemd-udev,
> unless it becomes completely independent. We still are waiting on the
> progress of vdev, patiently. So until then, it seems to be wait and see yet
> again.
>

vdev will ship with libudev-compat, which is ABI-compatible with the public
API of libudev 219. I'm afraid I couldn't manage ABI compatibility with
the private API, but AFAIK only udev and systemd were its clients anyway.
Also, vanilla libudev 219 doesn't overlap that much with systemd, so we can
easily build our own and ship that in place of libudev 220+ in the
near-term.

libudev-compat is still a work in progress, but it's my last major blocker,
and I hope to have something testable by early next week. The key
challenge has been in removing the need for the udev-controlled netlink
multicast group to deliver events while continuing to provide the same
semantics at comparable performance. While my approach almost certainly
won't be as fast as netlink-based libudev, it should:
* be fast enough for our purposes (will provide actual performance data
when I have them);
* be easier to troubleshoot (i.e. the admin can read, inject, reorder,
copy, and remove device events without having to instrument the device
manager, the kernel, or the libudev client);
* be agnostic to which device manager (if any) is running;
* let the admin control which root-context events get propagated to
containerized libudev clients (something udev and libudev *cannot* do, due
to their reliance on netlink).

You don't have to wait up for me, though--Devuan's udev and eudev are ready
to use now :) Developing vdev and libudev-compat is one of several
contingency plans for the scenario where udev and libudev become
intractably dependent on systemd.

-Jude