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 12:57:40 +0100

Le 16/11/2017 à 12:31, 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.
>
> 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
>
     Dear Laurent.

     Excuse me for insisting so long and off-topic. For my excuse let me
say my only will was to use mdevd *and* Xorg. I'm not fond of politics
more than you. Let's put an end to this thread.

     Didier
Received on Thu Nov 16 2017 - 11:57:40 UTC