| View previous topic :: View next topic |
| How do you manage your /dev |
| udev |
|
55% |
[ 33 ] |
| eudev |
|
31% |
[ 19 ] |
| mdev |
|
1% |
[ 1 ] |
| static /dev |
|
6% |
[ 4 ] |
| Something else?? |
|
5% |
[ 3 ] |
|
| Total Votes : 60 |
|
| Author |
Message |
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
 Posted: Tue Aug 08, 2023 10:36 pm Post subject: How do you manage your /dev |
 |
|
Recently, I've been looking through old threads.
There, I've seen plenty of people not happy with udev, the default way to manage your /dev.
However, I don't see many people talking about it recently.
Is everyone happy with how things are, or have all those people in the old threads moved somewhere else(BSD?, KISS?)?
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
 |
bstaletic
Apprentice
Joined: 05 Apr 2014
Posts: 253
|
| Posted: Wed Aug 09, 2023 2:15 am Post subject: |
|
|
Hello, to anyone reading! It's been years since I was last active in this forum.
Last time I was here, I had been using static /dev.
Huge thanks to Neddy for volunteering help with setting it up!
It worked fine, but dealing dozens of Arduino/FTDI/ARM/WhatNots always made me wonder...
| Quote: |
Is my /dev exactly as it should be?
|
My default answer was "of course not, as I have yet to fix it for this new device", even when no manual intervention had been necessary.
Plus, I had a terribly slow machine, so I reverted back to Arch.
A few Arch<->Gentoo cycles later, I am here again. This time I tried mdev. I never got it working in a satisfying way. For starters, I never got new devices to be detected on the fly... Reboots fix everything, though!
I understand that is just my inability to use mdev correctly, but if static /dev gives me fewer issues than mdev, I guess it can't be all my fault. So I went back to eudev.
Currently, eudev suffers from https://github.com/eudev-project/eudev/issues/249
but I am not affected. |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2022
|
| Posted: Wed Aug 09, 2023 9:33 am Post subject: |
|
|
Interesting. I thought I was using eudev, but I'd forgotten that Gentoo switched to udev back at the start of 2022 (check your "eselect news" for the announcement). Now I think some more about it, I thought {,e}udev had already been migrated to systemd-utils, that being the bits of udev and the like needed by OpenRc, and definitely not full systemd. A little worrying as udev is now masked for removal on 28th Aug 2023, though I guess my system will be automagicly changed to use systemd-utils.
systemd-utils ought to be one of the options in the poll, as IIUC it's been the recommended solution for some time, udev suffering from maintenance drying up.
FWIW I wash my systems with garlic-infused holy water to keep systemd out, but I'll let systemd-utils through.
_________________
Greybeard |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Wed Aug 09, 2023 9:55 am Post subject: |
|
|
| Goverp wrote: | Interesting. I thought I was using eudev, but I'd forgotten that Gentoo switched to udev back at the start of 2022 (check your "eselect news" for the announcement). Now I think some more about it, I thought {,e}udev had already been migrated to systemd-utils, that being the bits of udev and the like needed by OpenRc, and definitely not full systemd. A little worrying as udev is now masked for removal on 28th Aug 2023, though I guess my system will be automagicly changed to use systemd-utils.
systemd-utils ought to be one of the options in the poll, as IIUC it's been the recommended solution for some time, udev suffering from maintenance drying up.
FWIW I wash my systems with garlic-infused holy water to keep systemd out, but I'll let systemd-utils through. |
USE="udev" systemd-utils is udev.
Udev is part of systemd that is extracted by the gentoo devs as a standalone package.
For how long they are willing to do this and for how long will it even be possible is another question.
| Code: | !!! The ebuild selected to satisfy "systemd-utils" has unmet requirements.
- sys-apps/systemd-utils-253.7::gentoo USE="(split-usr) -acl -boot -kmod -secureboot (-selinux) -sysusers -test -tmpfiles -udev" ABI_X86="(64) -32 (-x32)"
The following REQUIRED_USE flag constraints are unsatisfied:
any-of ( boot tmpfiles sysusers udev ) |
AFAIK, sys-fs/udev does not build any files and it was merged into systemd-utils some time ago, along with other systemd shims.
| Code: | !!! All ebuilds that could satisfy "sys-fs/udev" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-fs/udev-250::gentoo (masked by: package.mask)
/var/db/repos/gentoo/profiles/package.mask:
# Mike Gilbert <floppym@gentoo.org> (2023-07-24)
# Migrated to sys-apps/systemd-utils.
# Removal on 2023-08-24. |
I don't let systemd into my pc, even it's shims.
| Code: | # go back to a static /dev
sys-fs/eudev
sys-fs/udev
virtual/udev
sys-auth/polkit
sys-auth/consolekit
sys-auth/rtkit
media-sound/pulseaudio
media-sound/pulseaudio-daemon
media-libs/libpulse
sys-apps/systemd
# purge systemd
#sys-apps/openrc::gentoo
sys-apps/systemd-utils |
The openrc part is commented out, so you can ignore it.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2022
|
| Posted: Wed Aug 09, 2023 11:53 am Post subject: |
|
|
| stefan11111 wrote: | ...
For how long they are willing to do this and for how long will it even be possible is another question.
... |
That quote is almost 10 years old. AFAIR the systemd proponents were told they could not tie the kernel to specific systemd versions in lock-step, and certainly kdbus in the kernel never happened.
_________________
Greybeard |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2022
|
| Posted: Wed Aug 09, 2023 11:59 am Post subject: |
|
|
| Goverp wrote: | | Interesting. I thought I was using eudev, but I'd forgotten that Gentoo switched to udev back at the start of 2022 (check your "eselect news" for the announcement). Now I think some more about it, I thought {,e}udev had already been migrated to systemd-utils, that being the bits of udev and the like needed by OpenRc, and definitely not full systemd. ... |
And I misread my logs! I'm already on systemd-utils, and have been since June last year.
_________________
Greybeard |
|
| Back to top |
|
|
pa4wdh
l33t
Joined: 16 Dec 2005
Posts: 815
|
| Posted: Wed Aug 09, 2023 12:37 pm Post subject: |
|
|
My systems run eudev, it's the only bit of systemd i have on my systems, and if i could i'd remove it.
Unfortunately i'm using lvm and dmcrypt which is highly impractical without any form udev, and as far as i know mdev doesn't handle that nicely.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world
My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21773
|
| Posted: Wed Aug 09, 2023 1:32 pm Post subject: |
|
|
| For those opposed to running udev, what is the motivation? Are there specific technical problems with the released udev we use today? Is this a philosophical objection since the systemd project hosts the udev code, and systemd's most active contributors have a history of questionable decisions, thereby tainting all projects in that repository? Is there a concern that an announced upcoming systemd-udevd change will introduce technical regressions relative to the currently released udev? |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Wed Aug 09, 2023 3:05 pm Post subject: |
|
|
| Hu wrote: | | For those opposed to running udev, what is the motivation? Are there specific technical problems with the released udev we use today? Is this a philosophical objection since the systemd project hosts the udev code, and systemd's most active contributors have a history of questionable decisions, thereby tainting all projects in that repository? Is there a concern that an announced upcoming systemd-udevd change will introduce technical regressions relative to the currently released udev? |
It's yet another program running on my system.
It's a program running as root at a very low level that is maintained by someone I don't trust.
It is too complex to reasonably have an understanding of what it does just my auditing the source code.
It needlessly increases attack surface and if it is exploited, my system is completely pwned(see points above).
It abstracts away what essentialy is file creation and a wrapper for mknod.
It does everything, loading modules, changing network interface names and probably more.
It is part of the systemd project, which tries to take over linux and make it near impossible to use anything else(look how much software depends on libudev just bacause, looking at you, wayland, xorg input drivers and pipewire). Steam notably got better here.
In my experience with udev, /dev/sd* nodes would often get swapped. That magically stopped happening after switching to a static /dev.
This behavior is documented on the arch wiki.
About your last question, I already linked a relevant email.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
mrbassie
l33t
Joined: 31 May 2013
Posts: 792
Location: over here
|
| Posted: Wed Aug 09, 2023 6:59 pm Post subject: |
|
|
| Hu wrote: | | For those opposed to running udev, what is the motivation? Are there specific technical problems with the released udev we use today? Is this a philosophical objection since the systemd project hosts the udev code, and systemd's most active contributors have a history of questionable decisions, thereby tainting all projects in that repository? Is there a concern that an announced upcoming systemd-udevd change will introduce technical regressions relative to the currently released udev? |
No, it's his hairdoo.Which is equal to
_________________
Bus conductors learned to code. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54391
Location: 56N 3W
|
| Posted: Wed Aug 09, 2023 8:51 pm Post subject: |
|
|
stefan11111,
| Quote: | It abstracts away what essentialy is file creation and a wrapper for mknod.
In my experience with udev, /dev/sd* nodes would often get swapped. |
Those points are not correct. I don't dispute your experience.
The kernel DEVTMPFS creates and removes /dev entries 'on the fly'
It signals userspace, then *udev fiddles with permissions, creates symbolic links ... whatever the rules say.
Internally, the kernel works with major,minor device numbers. Its OK to write root=<major>,<minor> in your bootloader config file, as long as your initrd init script knows how to pass that to the kernel.
Minor device number are allocated on a first come first served basis. That does not change with a static /dev. The device referenced as /dev/sda is still determined by the same kernel mechanism regardless of how /dev is managed.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Wed Aug 09, 2023 9:10 pm Post subject: |
|
|
| NeddySeagoon wrote: | stefan11111,
| Quote: | It abstracts away what essentialy is file creation and a wrapper for mknod.
In my experience with udev, /dev/sd* nodes would often get swapped. |
Those points are not correct. I don't dispute your experience.
The kernel DEVTMPFS creates and removes /dev entries 'on the fly'
It signals userspace, then *udev fiddles with permissions, creates symbolic links ... whatever the rules say.
Internally, the kernel works with major,minor device numbers. Its OK to write root=<major>,<minor> in your bootloader config file, as long as your initrd init script knows how to pass that to the kernel.
Minor device number are allocated on a first come first served basis. That does not change with a static /dev. The device referenced as /dev/sda is still determined by the same kernel mechanism regardless of how /dev is managed. |
Doesn't the kernel DEVTMPFS come with very few /dev nodes(/dev/null and such), and udev then created whatever new /dev nodes are needed, just like how mknod does?
I have an ssd and an hdd in my system.
With a static /dev. /dev/sda is always my ssd, and /dev/sdb is always my hdd.
With udev, these will sometimes be flipped.
I don't know if it's udev's fault or DEVTMPFS' fault.
From the arch wiki:
| Quote: | | udev handles separate events concurrently (in parallel), leading to a potential performance improvement over older systems. At the same time, this can complicate system administration, because, for example, the kernel module loading order is not preserved across boots. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations after reboot. For example, if the machine has two hard drives, /dev/sda may on next boot become /dev/sdb. See below for more info on this. |
As I understand that, it's because of udev's and more generally systemd's and Lennart's obsession with aggressive parallelization.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21773
|
| Posted: Thu Aug 10, 2023 12:13 am Post subject: |
|
|
You could check that easily enough, by booting a kernel into a virtual machine with no devices and no udev, and checking what is in devtmpfs. My experience has been that it is quite sufficient for an initramfs. It provides device nodes for SATA and NVMe disks. It provides null, console, and similar.
As Neddy said, you will not necessarily always get sda as your ssd. It depends on the order in which the kernel finds the devices. Perhaps your motherboard or other hardware is sufficiently slow in some places that the race practically always comes out the same way, but that does not mean there is no race.
Parallelization is a good thing. Consuming applications should always have their dependencies set such that all possible parallelization sequences work. Historically, many applications cheated in this area, with assumptions like that all drives are found before filesystems are mounted, or that all filesystems are mounted before programs in /usr are started (and so it is legal to run things in /usr/bin during early boot, because the calling program is late enough). When these assumptions became untrue, the applications broke. Parallelization is a major way to benefit from modern multi-core/multi-thread CPUs. Do you really want your entire system startup to be as serial as a build that runs under --jobs=1, even when some of those steps involve waiting for many seconds for a device to become ready? |
|
| Back to top |
|
|
sublogic
Apprentice
Joined: 21 Mar 2022
Posts: 222
Location: Pennsylvania, USA
|
| Posted: Thu Aug 10, 2023 1:10 am Post subject: |
|
|
| stefan11111 wrote: | | Doesn't the kernel DEVTMPFS come with very few /dev nodes(/dev/null and such), and udev then created whatever new /dev nodes are needed, just like how mknod does? |
About that specifically: in my initramfs rescue shell, before udev starts, (yes, the genkernel initramfs has udev !) the /dev has 134 entries; 97 of them are tty's. Plug in a thumb drive, it shows up. All the permissions are 0600 root:root . It's fine in a rescue shell but you might want some tweaks in your final userspace.
Udev changes the goups/permissions and add convenience links like /dev/disk/by-uuid.
(This is with CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y in the kernel config.) |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Thu Aug 10, 2023 9:53 am Post subject: |
|
|
I see some votes for something else??
May I ask what that something else is?
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Thu Aug 10, 2023 10:34 am Post subject: |
|
|
dd
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Last edited by stefan11111 on Thu Aug 10, 2023 10:43 am; edited 1 time in total |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Thu Aug 10, 2023 10:41 am Post subject: |
|
|
| Hu wrote: |
Parallelization is a good thing. Consuming applications should always have their dependencies set such that all possible parallelization sequences work. Historically, many applications cheated in this area, with assumptions like that all drives are found before filesystems are mounted, or that all filesystems are mounted before programs in /usr are started (and so it is legal to run things in /usr/bin during early boot, because the calling program is late enough). When these assumptions became untrue, the applications broke. Parallelization is a major way to benefit from modern multi-core/multi-thread CPUs. Do you really want your entire system startup to be as serial as a build that runs under --jobs=1, even when some of those steps involve waiting for many seconds for a device to become ready? |
In my case, without such parallelization, boot takes about 3 seconds.
Even on this, boot takes 10-15 seconds. I have a hard time believing anyone runs systems weaker than that.
If my build took 15 seconds max, I wouldn't mind building with -j1.
Parallelism comes with such races. Is to worth to parallelize and risk such races to save fractions of a second on boot?
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Thu Aug 10, 2023 10:42 am Post subject: |
|
|
| NeddySeagoon wrote: | stefan11111,
| Quote: | It abstracts away what essentialy is file creation and a wrapper for mknod.
In my experience with udev, /dev/sd* nodes would often get swapped. |
Those points are not correct. I don't dispute your experience.
The kernel DEVTMPFS creates and removes /dev entries 'on the fly'
It signals userspace, then *udev fiddles with permissions, creates symbolic links ... whatever the rules say.
Internally, the kernel works with major,minor device numbers. Its OK to write root=<major>,<minor> in your bootloader config file, as long as your initrd init script knows how to pass that to the kernel.
Minor device number are allocated on a first come first served basis. That does not change with a static /dev. The device referenced as /dev/sda is still determined by the same kernel mechanism regardless of how /dev is managed. |
I just tested on hardware and you're right.
It seems there is another way to manage /dev. DEVTMPVS and everything as root. or DEVTMPFS and the user manages /dev permissions.
Still, thing is broken with udev, thing works with static /dev. Why is that?
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54391
Location: 56N 3W
|
| Posted: Thu Aug 10, 2023 8:32 pm Post subject: |
|
|
stefan11111,
| Quote: | | It seems there is another way to manage /dev. DEVTMPVS and everything as root. |
Its worse than that. Everything is root:root So no sound or video acceleration, because its a really bad idea to add your user(s) to the root group
| Quote: | | or DEVTMPFS and the user manages /dev permissions. |
yes ... but DEVTMPFS is in RAM. It will be cleared every boot.
Still, thing is broken with udev, thing works with static /dev. Why is that?
It's an in kernel race. Sometimes you win and sometimes you don't
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Sun Aug 20, 2023 12:50 pm Post subject: |
|
|
| NeddySeagoon wrote: | stefan11111,
| Quote: | | It seems there is another way to manage /dev. DEVTMPVS and everything as root. |
Its worse than that. Everything is root:root So no sound or video acceleration, because its a really bad idea to add your user(s) to the root group
|
I have the pi1 that you helped me set up(thanks).
I have only 3 users that are actually used, root , openntpd and dnsmasq.
dnsmasq runs as user dnsmasq.
ntpd runs as user openntpd.
And so, I see no reason to have a non-root account.
After reading this thread, I decided to remove udev from my system and do this:
| Code: | # cat /etc/portage/profile/packages
-*virtual/dev-manager |
| Code: | # cat /etc/portage/package.use
app-alternatives/awk gawk
app-alternatives/bc gnu
app-alternatives/bzip2 reference
app-alternatives/cpio gnu
app-alternatives/gzip reference
app-alternatives/lex flex
app-alternatives/sh bash
app-alternatives/tar gnu
app-alternatives/yacc bison
sys-apps/portage native-extensions
sys-libs/ncurses -minimal
net-dns/dnsmasq dhcp |
| Code: | # cat /etc/portage/make.conf | grep USE
USE="-* git man ssl ipv6 asm minimal native-symlinks" |
Basically take the minimalism from my desktop and crack it up to 11.
Everything works as intended.
| Code: | # eix -I dev
No matches found |
| NeddySeagoon wrote: |
| Quote: | | or DEVTMPFS and the user manages /dev permissions. |
yes ... but DEVTMPFS is in RAM. It will be cleared every boot.
|
I said it's a choice, not a good choice.
Someone could probably write appropriate init scripts or something to make it work.
Looking at the poll:
It seems there are twice as many people using static /dev as I thought there would be.
Mdev is less popular than I thought.
Most people are too shy to comment.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1566
Location: South America
|
| Posted: Sun Aug 20, 2023 5:03 pm Post subject: |
|
|
| stefan11111 wrote: | | Most people are too shy to comment. |
Anyone, or just the ones who voted "Something else??"?
Initially, I had sys-fs/udev straight from the stage3 archive —the default implementation at the time—. Then I switched (manually and on purpose) to sys-fs/eudev some time after it became the default implementation for OpenRC-based Gentoo systems, then back again to sys-fs/udev (again, manually and on purpose) when eudev changed maintainers. And then let Portage migrate from sys-fs/udev to sys-apps/systemd-utils in one of my regular Gentoo updates.
I don't object to the udev concept. While the current implementation is provided by systemd's source archive, the concept predates systemd, and, in my opinion, udev performs a useful function.
As long the following two conditions are satisfied, I'm not worried by a threat made 9 years ago:
- sys-apps/systemd-utils can be used with an s6-based init system. Tested personally by me [1], and taken as a sign of init system independence, whatever systemd developers' opinion about running the udev parts without the rest of systemd is.
- The patchset for musl that sys-apps/systemd-utils applies [2] continues to work. Assumed by me while the package continues to be available for Gentoo's musl profiles.
To be honest, I find more worrying that an ABI incompatibility in eudev's libudev continues not being fixed, despite looking relatively simple to fix [3] and despite there being a significant number of people seemingly interested in eudev.
[1]
| Code: | PID TTY STAT TIME COMMAND
...
1 ? Ss 0:00 s6-svscan -X3 -- /run/service
...
93 ? S 0:00 s6-supervise systemd-udev
224 ? Ss 0:00 \_ /lib/systemd/systemd-udevd |
[2]
| Code: | MUSL_PATCHSET="systemd-musl-patches-253.3"
SRC_URI+=" elibc_musl? ( https://dev.gentoo.org/~floppym/dist/${MUSL_PATCHSET}.tar.gz )" |
[3] Judging by diff size in systemd's code, according to nekopsykose's contribution in the aforementioned GitHub issue.
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Sun Aug 20, 2023 6:00 pm Post subject: |
|
|
| GDH-gentoo wrote: | | stefan11111 wrote: | | Most people are too shy to comment. |
Anyone, or just the ones who voted "Something else??"?
|
Mostly those who voted "Something else??".
I expected more people to post in general, given that this ties to systemd and all.
When I made this, I expected >80% to vote udev. I'm glad I was wrong.
| GDH-gentoo wrote: |
Initially, I had sys-fs/udev straight from the stage3 archive —the default implementation at the time—. Then I switched (manually and on purpose) to sys-fs/eudev some time after it became the default implementation for OpenRC-based Gentoo systems, then back again to sys-fs/udev (again, manually and on purpose) when eudev changed maintainers. And then let Portage migrate from sys-fs/udev to sys-apps/systemd-utils in one of my regular Gentoo updates.
I don't object to the udev concept. While the current implementation is provided by systemd's source archive, the concept predates systemd, and, in my opinion, udev performs a useful function.
As long the following two conditions are satisfied, I'm not worried by a threat made 9 years ago:
- sys-apps/systemd-utils can be used with an s6-based init system. Tested personally by me [1], and taken as a sign of init system independence, whatever systemd developers' opinion about running the udev parts without the rest of systemd is.
- The patchset for musl that sys-apps/systemd-utils applies [2] continues to work. Assumed by me while the package continues to be available for Gentoo's musl profiles.
To be honest, I find more worrying that an ABI incompatibility in eudev's libudev continues not being fixed, despite looking relatively simple to fix [3] and despite there being a significant number of people seemingly interested in eudev.
[1]
| Code: | PID TTY STAT TIME COMMAND
...
1 ? Ss 0:00 s6-svscan -X3 -- /run/service
...
93 ? S 0:00 s6-supervise systemd-udev
224 ? Ss 0:00 \_ /lib/systemd/systemd-udevd |
[2]
| Code: | MUSL_PATCHSET="systemd-musl-patches-253.3"
SRC_URI+=" elibc_musl? ( https://dev.gentoo.org/~floppym/dist/${MUSL_PATCHSET}.tar.gz )" |
[3] Judging by diff size in systemd's code, according to nekopsykose's contribution in the aforementioned GitHub issue. |
If I was constantly plugging devices in and out, I might have looked into a dynamic /dev.
Given I rarely use things like usb's, and when I do I don't want things like auto mounting and such, a static /dev works fine for me.
In fact, I could probably use a stage3 /dev and be fine.
How many of those who use eudev are devs?
I would expect that the actual devs either don't care about udev or do something unrelated to udev.
Wasn't eudev in a pretty bad state maitainer-wise, until some devs decided to keep it afloat?
I never looked at the actual code to see how easy/hard the change would be
| Code: | $ eselect news list | grep udev
[12] 2021-08-24 eudev retirement on 2022-01-01 |
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Mon Sep 11, 2023 7:14 pm Post subject: |
|
|
Choice is further restricted:
| Code: | # Andreas K. Hüttel <dilfridge@gentoo.org> (2023-09-11)
# Dead project accumulating open bugs and incompatibilities.
# No maintainer commits since February 2021.
# Bugs 673834, 713106, 753134, 667686, 771705, 668880, 770358, 851255,
# 711462, 904741, ... Removal in 30 days.
sys-fs/eudev |
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54391
Location: 56N 3W
|
| Posted: Mon Sep 11, 2023 7:27 pm Post subject: |
|
|
stefan11111,
eudev is not currently feature compatible with udev. That means that its not the drop in replacement it one was.
While its like that, its not usable.
If choice has been restricted, its due to bit rot from the new upstream, rather than Gentoo developers.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
stefan11111
l33t
Joined: 29 Jan 2023
Posts: 922
Location: Romania
|
| Posted: Mon Sep 11, 2023 8:20 pm Post subject: |
|
|
| NeddySeagoon wrote: | stefan11111,
eudev is not currently feature compatible with udev. That means that its not the drop in replacement it one was.
While its like that, its not usable.
If choice has been restricted, its due to bit rot from the new upstream, rather than Gentoo developers. |
I thought that a dynamic /dev manager had to manage a temporary /dev. Does eudev not do that?
Last upstream commit was 3 weeks ago. I'd hardly call that unmaintained.
From the same ml thread:
| Quote: | On the link above it says this:
On 2021-08-20 Gentoo decided to abandon eudev and a new project was
established on 2021-09-14 by Alpine, Devuan and Gentoo contributors
(alphabetical order).
It seems to have a upstream that is active but no one is maintaining it
on Gentoo. Basically, it needs a Gentoo maintainer now. It would seem
given the time span that no one wants to take it.
Like others, I use it but didn't know it wasn't maintained anymore. I
hope someone will step up but if not, looks like we have to use udev.
Dale
|
So it is a gentoo issue.
In light of the recent libgudev incompatibility, one can do one of the following things listed it this thread.
_________________
My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
