From: Tristan de Cacqueray <tristan@midirus.com>
To: Takashi Iwai <tiwai@suse.de>, Miguel Ojeda <ojeda@kernel.org>
Cc: linux-sound@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org,
Tristan de Cacqueray <tristan@midirus.com>
Subject: [PATCH RFC 0/3] rust: snd: Introduce experimental ALSA rawmidi abstractions
Date: Sun, 11 Oct 2026 13:02:11 +0000 [thread overview]
Message-ID: <20261011-rust-snd-v1-0-7974ecdcd345@midirus.com> (raw)
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.
2. Is rawmidi a useful initial target for ALSA Rust abstraction?
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.
Testing:
- build with CONFIG_RUST=y and CONFIG_SAMPLE_RUST_MIDI_DEVICE=m.
- Run amidi client to receive events from Rust:
amidi -l # to get the hw number
amidi -d -S "424344" -p hw:1,0
- Modprobe/rmmod works, but I haven't reproduced the race between
rawmidi substream and disconnect.
Base: rust-next at 2dee3d3adcad
This is my first contribution to the kernel, suggestions on routing or
RFC scope are welcome.
Thanks!
-Tristan
Signed-off-by: Tristan de Cacqueray <tristan@midirus.com>
---
Tristan de Cacqueray (3):
rust: snd: Add initial snd_card binding
rust: snd: Add snd_rawmidi binding
rust: snd: Add active rawmidi_substream helper
rust/bindings/bindings_helper.h | 2 +
rust/kernel/lib.rs | 2 +
rust/kernel/snd.rs | 403 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
samples/rust/Kconfig | 11 +++
samples/rust/Makefile | 1 +
samples/rust/rust_midi_device.rs | 159 ++++++++++++++++++++++++++++++++++++++++
6 files changed, 578 insertions(+)
---
base-commit: 2dee3d3adcadcc57d62ba6608cd02f50b0c10264
change-id: 20261011-rust-snd-c5e596867624
Best regards,
--
Tristan de Cacqueray <tristan@midirus.com>
next reply other threads:[~2026-10-11 13:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-11 13:02 Tristan de Cacqueray [this message]
2026-10-11 13:02 ` [PATCH RFC 1/3] rust: snd: Add initial snd_card binding Tristan de Cacqueray
2026-10-11 13:02 ` [PATCH RFC 2/3] rust: snd: Add snd_rawmidi binding Tristan de Cacqueray
2026-10-11 13:02 ` [PATCH RFC 3/3] rust: snd: Add active rawmidi_substream helper Tristan de Cacqueray
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=20261011-rust-snd-v1-0-7974ecdcd345@midirus.com \
--to=tristan@midirus.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tiwai@suse.de \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®