Skip to main content ↑ ↓
Topic: Why is Artix using eudev? (Read 9285 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Why is Artix using eudev?

Reply #30 –
Why was this marked as solved...

Re: Why is Artix using eudev?

Reply #31 –
Because is solved 🤔 We need no more discuss about this. Eudev is still need and IF will exist another option, which will really works, we will use it, if that will be necessary.
Actually we have Eudev and xudev. Users can use every another alternatives what they want,  but we they should not ask here if some not works. We provide no support for alternatives now... Because we need keep stable system 😉

You can play with alternatives so much how you like... But what we use in upstream is business of us and our developers.

Re: Why is Artix using eudev?

Reply #32 –
Quote from: yolkano – on
Why was this marked as solved...
If you are really interested to develop udev-free Artix, you can create custom repo with rebuilt packages or at least maintain corresponding packages in AUR
Btw, there was a topic with logind alternative recently, i think, these ideas can be merged in a single repo
ARMtix
If you need to contact me, use email
 

Re: Why is Artix using eudev?

Reply #33 –
Quote from: phoenix_king_rus – on
If you are really interested to develop udev-free Artix, you can create custom repo with rebuilt packages or at least maintain corresponding packages in AUR
Btw, there was a topic with logind alternative recently, i think, these ideas can be merged in a single repo
That would be a good idea to put all of these alternatives in a single place so maybe one day we can group them together and get something working  8)

EDIT: Can you link to the logind alternative?

Re: Why is Artix using eudev?

Reply #34 –
Quote from: yolkano – on
That would be a good idea to put all of these alternatives in a single place so maybe one day we can group them together and get something working  8)
There is already a bunch of noudev (marked by this name) packages in AUR, you can maintain them. I didn't update some of them for a while since currently i can't test if they work

Quote from: yolkano – on
EDIT: Can you link to the logind alternative?
https://forum.artixlinux.org/index.php/topic,2269.msg15144.html#msg15144
ARMtix
If you need to contact me, use email

Re: Why is Artix using eudev?

Reply #35 –
Thanks for the link, but it seems that seatd also uses elogind as a possible backend, which leads us to the same conclusion.

Guess there's no alternative other for now?

Re: Why is Artix using eudev?

Reply #36 –
Any updates on this?

Re: Why is Artix using eudev?

Reply #37 –
I digged a bit into libudev-zero code. It seems, if someone wants to use it, everything depending on libudev must be rebuilt against it. Also i don't like its design in terms of uevents processing: it uses inotify on some directory where these uevents are put by some extra program. The problem is that there is no mechanism to clean them. Maybe there can be more problems since i only checked the part responsible for hotplug.
Regarding the former, a separate repo(s) will be needed most likely for these packages (unless Artix decides to create libudev-specific packages). Regarding the latter, i have an idea to make alternative "backend" based on bus but it will require patching also. This is no more than just an idea atm.
ARMtix
If you need to contact me, use email

Re: Why is Artix using eudev?

Reply #38 –
we tried seatd, unfortunately, as it stands, it doesn't seem very useful. brings more problems than it solves.

Re: Why is Artix using eudev?

Reply #39 –
Quote from: phoenix_king_rus – on
It seems, if someone wants to use it, everything depending on libudev must be rebuilt against it
It seems, i was wrong about this. A small test in VM with libeudev replaced by libudev-zero (but eudev was still device manager) has shown that X can be started without any rebuilds. It even had mouse working (i didn't test keyboard but i'm sure it will work too) using libinput driver. This means libudev-zero at least provides info about already existing devices. I didn't test hotplug though but i think it will also work then.
ARMtix
If you need to contact me, use email

Re: Why is Artix using eudev?

Reply #40 –
it doesn't matter ... we don't plan to remove eudev / xudev, seatd is not an alternative, so there's not much to talk about. who wants to experiment can .. but only on their own computer. ;)

Re: Why is Artix using eudev?

Reply #41 –
Well well well, looks like "eudev" is getting deprecated...

Re: Why is Artix using eudev?

Reply #43 –
Quote from: yolkano – on
Well well well, looks like "eudev" is getting deprecated...

Artix has already switched to systemd udev (or as it was called, xudev), though the package is still called "eudev" (likely for compatibility reasons). I was like "wait a minute, did I just get systemd'd?" when "Starting version 249.3-3-artix" showed up on boot today...

Quote
I don't like its design in terms of uevents processing: it uses inotify on some directory where these uevents are put by some extra program. The problem is that there is no mechanism to clean them. Maybe there can be more problems since i only checked the part responsible for hotplug.

A somewhat recent commit allows uevents to be rebroadcast using Netlink, which doesn't pollute a directory while still allowing hotplugging to work. This requires special support in the daemon, though (skarnet's mdevd, for instance).

Re: Why is Artix using eudev?

Reply #44 –
Quote from: capezotte – on
A somewhat recent commit allows uevents to be rebroadcast using Netlink, which doesn't pollute a directory while still allowing hotplugging to work. This requires special support in the daemon, though (skarnet's mdevd, for instance).
There is also helper script for other device managers. This update is already reflected in the corresponding AUR packages
ARMtix
If you need to contact me, use email