Re: [PATCH RFC 0/3] rust: snd: Introduce experimental ALSA rawmidi abstractions

[Takashi Iwai <tiwai@suse.de>]

On Sun, 11 Oct 2026 15:02:11 +0200,
Tristan de Cacqueray wrote:
> 
> Hi Takashi and the Rust for Linux maintainers.
> 
> I just noticed your mail about an early Rust prototype for the sound
> subsystem right before I was about to submit this RFC!
>   https://lore.kernel.org/alsa-devel/878q48579z.wl-tiwai@suse.de/
> 
> Nevertheless, please allow me to share what I had in mind through this
> small proof of concept for the `rawmidi` API. I am looking for feedback on
> the scope, coordination, and the ownership model rather than a detailed
> review for merging.
> 
> My use case is a new hardware controller using a custom serial protocol.
> While developing its Rust driver, I needed an interface to ALSA rawmidi.
> I'm particularly interested in handling rawmidi substream safely to avoid
> issues like the one fixed by
>   221253723dc5 ("ALSA: bcd2000: Fix race between rawmidi and disconnect")
> 
> So, I wrote some bindings to see how that would look like. This series adds
> experimental snd_card and snd_rawmidi wrappers, input/output callback
> traits, and a sample rawmidi faux device using delayed work to simulate
> incoming MIDI data.
> 
> This is not merge-ready. In particular, the prototype does not yet enforce
> the devres lifetime of the card or the lifetime of its rawmidi wrapper. The
> substream helper also relies on the driver clearing it before close
> returns.
> 
> Here are my questions:
> 
>   1. Does this rawmidi experiment overlaps with your prototype?
>      If so, I would be happy to coordinate or adapt this experiment to it.

No, my patchset doesn't contain rawmidi support yet.
The sound card abstraction would conflict quite, sure, but it wouldn't
be too hard to adapt, I guess.

>   2. Is rawmidi a useful initial target for ALSA Rust abstraction?

Sure, why not, if it's actually needed? :)

>   3. Does your prototype mirror the C API 1:1, or for example, does it hide
>      the substream lifecycle? That's the design choice I'm least sure about.

It's mostly a straightforward wrapping of C API, but there are a few
twists to adapt Rust-way.  The card can be managed in RAII style, too,
for example.

I haven't prepared for submission, but you can find the current
changes in test/sound-rust branch of sound git tree (either kernel.org
or github.com):
  https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=test/sound-rust
  https://github.com/tiwai/sound/tree/test/sound-rust
  
Those are over 50 commits on top of 7.3-rc5, and I'll likely rebase a
bit to rearrange before submission, so beware of changes in future.

The commits begin with a few Rust kernel changes for fixing and
addition for the sound support, including the PM support from Beata
Michalska (just took what have been posted), followed by ALSA core
abstractions for the card, PCM and controls.

Then it continues to the implementations of 3 actual sound drivers for
PCM/control: the dummy driver (with platform and hrtimer), and the
ens1370 and intel8x0 drivers for PCI devices to be run on VM.

After that, the extension to USB abstraction follows, including the
isochronous support patches by Colin Braun, and then the USB-audio
driver implementation (that can run on an actual bare metal), as well
as the USB runtime PM support.


BTW, until now, I haven't planned for any serious consideration to
merge Rust stuff yet.  Partly because the above was a pure experiment
for me, but another big obstacle is that the whole Rust C binding is
limited to built-in vmlinux.  With a distribution kernel maintainer
hat on, this is absolutely NO-GO -- we really want to avoid built-in.
(Graphics is a kind of exception nowadays because of boot support,
though.)  Can this be worked out soon...?


thanks,

Takashi