patches and low-level development discussion
 help / color / mirror / code / Atom feed
From: Demi Marie Obenour <demiobenour@gmail.com>
To: Spectrum OS Development <devel@spectrum-os.org>
Subject: Switching to udev?
Date: Wed, 23 Jul 2025 13:34:56 -0400	[thread overview]
Message-ID: <aefe36d5-2924-439e-b093-be78d0de7fa0@gmail.com> (raw)


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

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

             reply	other threads:[~2025-07-23 17:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-23 17:34 Demi Marie Obenour [this message]
2025-07-23 18:59 ` Switching to udev? Demi Marie Obenour
2025-07-26 10:06   ` Alyssa Ross
2025-07-27 21:36     ` Demi Marie Obenour
2025-07-29  7:29       ` Alyssa Ross
2025-07-29  7:48         ` Demi Marie Obenour
2025-08-20 17:11           ` Alyssa Ross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aefe36d5-2924-439e-b093-be78d0de7fa0@gmail.com \
    --to=demiobenour@gmail.com \
    --cc=devel@spectrum-os.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://spectrum-os.org/git/crosvm
	https://spectrum-os.org/git/doc
	https://spectrum-os.org/git/mktuntap
	https://spectrum-os.org/git/nixpkgs
	https://spectrum-os.org/git/spectrum
	https://spectrum-os.org/git/ucspi-vsock
	https://spectrum-os.org/git/www

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).