>The only fragment in xf86-input-evdev that requires libudev is
>(from src/evdev.c, with some changes in whitespaces):
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.
Because if it's that single piece of code, it's indeed very easy
to replace... at least from a technical standpoint.
From a political standpoint, it's a wholly different matter. The
problem is that "people" - I don't know exactly who, but kernel
folks seem to be in on this - have decided that applications should
never access sysfs directly, and instead they should contact an
"intermediary layer" that is the only one allowed to interact with
sysfs.
In theory that makes sense, and the reason why kernel folks are
behind it is it allows them to more or less break sysfs at will.
Linus has said, multiple times, that sysfs wasn't supposed to be a
stable interface, so applications should just not access sysfs.
The problem is that it basically requires the intermediary layer
to fully duplicate the sysfs data in userspace, and provide users
with a way to access the cached data. That is exactly what udevd and
libudev do, and from a software design point, it's a terrible idea:
- it duplicates data, and duplication leads to inconsistencies
- it introduces a SPOF in the form of udevd
- it politically enforces libudev as the de facto standard that
everyone needs to use, whether you like it or not (this is the
vendor lock-in I'm talking about)
- the presence of a wrapper layer generally introduces more
bloat than it solves problems; sysfs has not changed interfaces to the
point of breaking stuff in 12 years and counting
- ...
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.
--
Laurent
Received on Wed Nov 15 2017 - 14:53:21 UTC