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:jud...@gmail.com> Sent: 6/1/2015 6:58 PM To: James Powell<mailto:james4...@hotmail.com> Cc: dng@lists.dyne.org<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
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng