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

[Laurent Bercot]

   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.


 It's ok. It's not off-topic: I wrote mdevd, so I should expect those
discussions.

 Casper brought a good point: libudev is also about allowing 
applications

to access the uevent stream, in a dynamic way, i.e. more flexible than
just the mdev.conf configuration file. I will think about a simple way
to do the same.

--
 Laurent

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

[Didier Kryn]

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

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

[Laurent Bercot]

   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

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

[Didier Kryn]

Le 16/11/2017 à 10:25, Casper Ti. Vector a écrit :

On Wed, Nov 15, 2017 at 02:53:21PM +, Laurent Bercot wrote:

  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.

Unfortunately, just as noted by Guillermo, libudev is also, in more
complicated ways, needed by quite a few x11 drivers and (perhaps most
importantly) xserver itself.  I apologise for (again) not thoroughly
investigating the issues before replying :(


  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.

(Again, I am not someone fluent in low level programming, so please feel
free to correct me if I make stupid mistakes in the following.)

 From my cursory glance at the x11 code that use libudev, and the libudev
documentation, the main functionalities of libudev seem to fall into two
almost orthogonal categories: those that abstract the sysfs interface,
and those that handle the udev event queue.  I have not come up with a
good idea on how to provide the latter in a vender-neutral way, but a
neutral design of the former seems obvious: if sysfs was really never
intended to be a stable interface at all, at least make a minimalist
library outside udev that provide the necessary functionalities.

However, as you noted, "sysfs has not changed interfaces to the point of
breaking stuff in 12 years and counting", so the intended instability is
not really an excuse; and even if we pretend that sysfs is so unstable,
stating that sysfs is "a private export only to be consumed by udev" [1]
(ie. not mdev, nldev, vdev, etc.) has no technical basis.  But noticing
that the actors in the drama include GKH and KS, this is unsurprising;
this is also the reason I refered to the conspiracy theory again.

[1] 

I agree that there is a conspiracy. The mails exchanged by Rob 
Landley are very explicit.


I don't think Linus Torvalds would tolerate on the long term that a 
group of people develop a private kernel interface for the purpose of 
forcing systemd to all Linux users. In fact I guess he is aware of this, 
and even sensitive to the bad quality of their code, but he will not 
move because only one person complains.


Rob Landley would have a stronger argument if a large number of 
users had their desktops running mdev and undocumented changes in sysfs 
breaks it.


Didier

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

[Casper Ti. Vector]

On Wed, Nov 15, 2017 at 02:53:21PM +, Laurent Bercot wrote:
>  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.

Unfortunately, just as noted by Guillermo, libudev is also, in more
complicated ways, needed by quite a few x11 drivers and (perhaps most
importantly) xserver itself.  I apologise for (again) not thoroughly
investigating the issues before replying :(

>  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.

(Again, I am not someone fluent in low level programming, so please feel
free to correct me if I make stupid mistakes in the following.)

>From my cursory glance at the x11 code that use libudev, and the libudev
documentation, the main functionalities of libudev seem to fall into two
almost orthogonal categories: those that abstract the sysfs interface,
and those that handle the udev event queue.  I have not come up with a
good idea on how to provide the latter in a vender-neutral way, but a
neutral design of the former seems obvious: if sysfs was really never
intended to be a stable interface at all, at least make a minimalist
library outside udev that provide the necessary functionalities.

However, as you noted, "sysfs has not changed interfaces to the point of
breaking stuff in 12 years and counting", so the intended instability is
not really an excuse; and even if we pretend that sysfs is so unstable,
stating that sysfs is "a private export only to be consumed by udev" [1]
(ie. not mdev, nldev, vdev, etc.) has no technical basis.  But noticing
that the actors in the drama include GKH and KS, this is unsurprising;
this is also the reason I refered to the conspiracy theory again.

[1] 

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

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

[Didier Kryn]

Le 16/11/2017 à 03:01, Guillermo a écrit :

2017-11-15 14:11 GMT-03:00 Didier Kryn:

 I don't know what evdev is (I guess some virtual device) and what's its
place in the big Xorg picture, but I think some of you guys know it. Any
usefull link?

X11 comes in pieces; there is the server, normally installed as
/usr/bin/X and / or /usr/bin/Xorg, and modules, that e.g. Devuan
installs in /usr/lib/xorg/modules, I believe, and that include the
video drivers (/usr/lib/xorg/modules/drivers) and input drivers
(/usr/lib/xorg/modules/input). Evdev an input driver (i.e. it handles
the keyboard, mouse, etc.) that IIUC uses Linux' event interface
(CONFIG_INPUT_EVDEV, "Say Y here if you want your input device events
be accessible under char device 13:64+ - /dev/input/eventX in a
generic way").

You can see which modules are loaded by X at startup in its log file
(normally /var/log/Xorg*.log), and if your computer has the package
that provides the evdev driver installed, see 'man evdev'.

2017-11-15 11:53 GMT-03:00 Laurent Bercot:

  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.

Indeed it is. The X server itself:

* https://cgit.freedesktop.org/xorg/xserver/tree/config/udev.c

The modesetting video driver:

* 
https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesetting/drmmode_display.c
(drmmode_*uevent*())

The Intel video driver:

* 
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/uxa/intel_driver.c
(I830*UEvent*())

The amdgpu video driver:

* 
https://cgit.freedesktop.org/xorg/driver/xf86-video-amdgpu/tree/src/drmmode_display.c
(drmmode_*uevent*())

And probably more. Although it seems that in most cases the dependency
on the libudev API is selectable by an option at compile time.

G.


IIUC evdev merges inputs from various devices, keyboard(s), 
mouse(s) and touchpad(s). But autoconfig has mostly to do with display 
size and shape, and this is rather an output device. Sorry, this is 
becoming off-topic.


Didier

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

[Didier Kryn]

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