Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

From: Didier Kryn <didier.kryn_at_free.fr>
Date: Thu, 16 Nov 2017 09:13:52 +0100

Le 15/11/2017 à 19:27, Laurent Bercot a écrit :
>> "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.
>
> --
> Laurent
>
     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
abstraction layer.

     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 :-)

     Didier
Received on Thu Nov 16 2017 - 08:13:52 UTC