Le 15/11/2017 à 19:27, Laurent Bercot a écrit :
I fully understand that this list is focused on good programming
practice and libudev is considered something disgusting in that respect.
My question was triggered by the frustration, probably shared by many,
of not being able to replace Udev by Mdev or Mdevd, only because Xorg
autoconfig has become a must. Using the same API as libudev isn't
necessary, because Xorg might be patched to use a different one, but
what is needed is to hide the unstability of sysfs by some run-time
"Applications should not access sysfs" doesn't mean there should
be only one version of the intermediate library. There's already
Systemd-Udev and Eudev versions, at least. For the case of Xorg, it
just means sysfs access should not be hard-coded in the source of
Xorg, but there should be some library in between, so that it is not
necessary to recompile Xorg for every version of the kernel. So any
replacement for the needed subset of libudev would do it.
Yes, but that's the whole point: the needed information is available
as is in sysfs, and putting a library in-between is 100% bloat. It's
just about testing something in the device path, and the device path
is just that - a path in sysfs. The way libudev proceeds to get
that information is entirely more complex than necessary - it even adds
operations that can fail, such as memory allocation, when it is
entirely useless here; but with the way the libudev architecture is
designed, it is the only way, and there's no escaping the bloat,
added SPOF, added failure points.
There is _no good way_ to implement the interesting parts of
EvdevDeviceIsVirtual() without directly accessing sysfs. It's either
sysfs, or libudev, or a libudev replacement that would, by design,
necessarily be just as bad as libudev.
Replacing systemd-udev by something simpler and well done, like
mdev or mdevd is not only a technical, but also a crucial political
issue for software freedom. So hopping somebody with the skills will
come out with a good idea :-)