On Wed, Nov 15, 2017 at 02:53:21PM +0000, Laurent Bercot wrote:
> Is it really the only place in Xorg that depends on libudev?
> I'd think it would be much, much more entangled with libudev than
> this.
Unfortunately, just as noted by Guillermo, libudev is also, in more
complicated ways, needed by quite a few x11 drivers and (perhaps most
importantly) xserver itself. I apologise for (again) not thoroughly
investigating the issues before replying :(
> So, yeah. If you want a patch for xf86-input-evdev that will
> make it stop depend on libudev, I can write one in an hour. But
> that patch will likely never go upstream, because it goes against
> policy; and complying with the policy would basically amount to
> rewriting libudev and making a new udevd. Which I believe I'm quite
> able to do, and better than the existing ones, but it would still be
> bad software design, and I have no interest in contributing to the
> problem.
(Again, I am not someone fluent in low level programming, so please feel
free to correct me if I make stupid mistakes in the following.)
>From my cursory glance at the x11 code that use libudev, and the libudev
documentation, the main functionalities of libudev seem to fall into two
almost orthogonal categories: those that abstract the sysfs interface,
and those that handle the udev event queue. I have not come up with a
good idea on how to provide the latter in a vender-neutral way, but a
neutral design of the former seems obvious: if sysfs was really never
intended to be a stable interface at all, at least make a minimalist
library outside udev that provide the necessary functionalities.
However, as you noted, "sysfs has not changed interfaces to the point of
breaking stuff in 12 years and counting", so the intended instability is
not really an excuse; and even if we pretend that sysfs is so unstable,
stating that sysfs is "a private export only to be consumed by udev" [1]
(ie. not mdev, nldev, vdev, etc.) has no technical basis. But noticing
that the actors in the drama include GKH and KS, this is unsurprising;
this is also the reason I refered to the conspiracy theory again.
[1] <
https://landley.net/notes-2015.html#05-07-2015>
--
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Thu Nov 16 2017 - 09:25:34 UTC