One concern I have is how GNOME will manage gudev. One thing I don't want to think about is them creating some dependency upon systemd in some way preventing portability to extracted udev or something that is udev compatible like vdev requiring gudev to be either heavily patched or redeveloped, such as a gvdev project.

It's mind numbing to consider all this, but the rate they are trying to tighten their grip, at least we do know the more alternatives seem to supplicant things enough to keep pro-choice distributions slipping through their fingers.

-Jim
________________________________
From: Jude Nelson<mailto:judecn@gmail.com>
Sent: ‎6/‎1/‎2015 6:58 PM
To: James Powell<mailto:james4591@hotmail.com>
Cc: dng@???<mailto:dng@lists.dyne.org>
Subject: Re: [Dng] New systemd release notes regarding udev.

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