mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>



             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®