> 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.
And do you think it's fair to direct that frustration at people who
have
nothing to do with its causes and cannot do anything about it, instead
of
the people in charge?
The issue is not a technical one: it's a political one. I can provide
technical solutions to technical problems, but if you want to tackle
political problems, you will need someone with more political power
and more willingness to do politics.
>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
Apparently I was not clear enough, so let me repeat: replacing udev
with
something simpler and well done is, AFAICT, impossible as long as you
stick to the notion of "hide the unstability of sysfs by some run-time
abstraction layer". The run-time abstraction layer is exactly what
libudev is; if you start with the same concepts as udev and implement
from
there, you *will* end up with udev, there's no way around it.
Maybe an alternative implementation of libudev would be better; it
probably would, because given freedesktop.org's (and especially Kay
Sievers') history, chances are the current implementation of libudev is
terrible. But a new implementation *would not solve the underlying
issue*. Any gains would only be marginal; a new API could be somewhat
different,
but not different enough from libudev's API to be worth it. At the end
of the day, it would just split up the software ecosystem and incur
maintenance costs, for what? the satisfaction of not having GKH and KS
control uevent management in Xorg, knowing full well that the
alternative
does the exact same thing as libudev with the exact same issues,
minus some minor implementation ones?
When I look at libudev, I see a bunch of bloaty wrappers and generic
functionality put in a nice package and enforced on people. I don't
like it any more than you do, but the real fix is to do away with the
need for that bloat in the first place; it definitely is not to go NIH
and say "ok, we'll do our own libudev, which will be just as useless,
but
at least it won't be yours, nyah nyah nyah".
I'm interested in writing code that does real things, not in writing
bloaty wrappers, even if I know that MY bloaty wrappers would be the
best bloaty wrappers ever.
Tell you what, I do have an idea for a libudev alternative: in your
application, you write your code *exactly* as you would if you were
accessing the files in sysfs directly, except you don't access files
under /sys, you access files under /definitelynotsys instead. And
you defer the responsibility of the /sys to /definitelynotsys mapping
to a third-party layer; I can even be that third party, if you want.
Nobody can blame you: you're not accessing sysfs, you're just using
my API. And it's nobody's business if a common implementation of my API
is making /definitelynotsys a symlink to /sys.
--
Laurent
Received on Thu Nov 16 2017 - 11:31:12 UTC