Re: Switching to udev?

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3644 bytes --]

On 7/23/25 13:34, Demi Marie Obenour wrote:
> I'm seriously wondering if Spectrum should switch from mdevd to udev.
> It's where all of the upstream device detection work happens, and
> it would avoid needing to statically configure sound devices for
> PipeWire.
> 
> The current PipeWire patch statically creates devices.  This works
> for VMs because VMs are statically configured and only have virtio
> devices.  This was also the most challenging part of the effort,
> and I still had to guess some of the parameters.  Supporting hotplug
> would require either a custom PipeWire module, a custom daemon that
> talked to PipeWire, keeping pw-cli running in interactive mode,
> or patches to PipeWire to make device lingering work.
> 
> In the audio case, ALSA expects device paths of the form
> hw:card:device:subdevice.  However, I don't believe card numbers are
> stable: they reflect the order in which the kernel enumerates devices,
> and that is not at all guaranteed.  A VM that only has a virtio sound
> device will only ever have card 0, device 0, and subdevice 0, so
> hard-coding hw:0,0,0 is fine.  This is not true if physical hardware
> is present.  That requires a lot of device identification logic, and
> all of the upstream work on that is in udev or the systemd hardware
> database (which udev also uses).
> 
> In the future, there may be other projects Spectrum wants to use that
> rely on udev for enumerating devices.  Some of them might *only* support
> PipeWire and have no other means of configuration.  Even if other means
> of configuration *exist*, I expect them to be very rarely used by
> upstream and thus poorly tested.
> 
> tl;dr: you can get away without udev in VMs, but I expect problems
> with physical hardware, and I want to switch to udev as a preemptive
> measure to avoid those problems and to ease development.

From https://wiki.gentoo.org/wiki/Mdev:

- udev is needed to load firmware for AMD Radeon GPUs.
- libusb will not see USB devices unless deprecated kernel
  configuration options are set.

From https://wayland.freedesktop.org/libinput/doc/latest/architecture.html:

- Wayland compositors use udev (via libinput) to support
  device hotplugging.  This is needed for USB keyboard
  and/or mouse support, which is a hard requirement for
  desktops that don't have PS/2 connectors (almost all of
  them I believe).
- libinput relies on udev to determine what kind of device
  an input device is.

FreeBSD also switched to udev for Mutter.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271824#c4
states that for Wayland, udev is essentially required.  Even
Gentoo uses udev, though systemd is not the default init
system.

I think avoiding udev is a losing battle in the long run,
except possibly for VMs that will never ever have physical
hardware attached to them.  That would require configuring
VMs with and without physical hardware separately, which
I would strongly prefer to avoid.  If the memory
consumption or disk space requirements of udev are
excessive, I think this would be better addressed as part
of a broader debloating effort.

libudev-zero does exist, but it doesn't work with PipeWire
(https://github.com/illiliti/libudev-zero/issues/26, still
unfixed despite being closed) and there are other problems
with it as shown by its issue tracker.  Alpine's wiki doesn't
recommend it for desktop environments, and while Spectrum VMs
don't run full desktop environments they do run desktop
software.  Such software requires udev more and more nowadays.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]