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
