linux-kernel - Re: [PATCH 2/2] samples: rust: add a USB driver sample

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <9657C897-087E-4544-849B-964E99D95A50@collabora.com>
Date: Sat, 6 Sep 2025 11:50:50 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <lossin@...nel.org>,
 Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>,
 linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org,
 linux-usb@...r.kernel.org
Subject: Re: [PATCH 2/2] samples: rust: add a USB driver sample

Hi Danilo,

> On 6 Sep 2025, at 10:22, Danilo Krummrich <dakr@...nel.org> wrote:
> 
> On Sat Sep 6, 2025 at 2:41 PM CEST, Daniel Almeida wrote:
>>>> 
>>>> I thought that an iterative approach would work here, i.e.: merge this, then
>>>> URBs, then more stuff, etc.
>>> 
>>> Ah, that makes sense, I didn't realize you want that here.  What USB
>>> device do you want to write a rust driver for?  Are you going to need
>>> bindings to the usb major number, or is it going to talk to some other
>>> subsystem instead?
>>> 
>>> Right now, these bindings don't really do anything USB specific at all
>>> except allow a driver to bind to a device.
>>> 
>>> thanks,
>>> 
>>> greg k-h
>> 
>> To be honest, I'm trying to pave the way for others.
>> 
>> I often hear people saying that they would look into Rust drivers if only they
>> did not have to write all the surrounding infrastructure themselves. On the
>> other hand, there is no infrastructure because there are no drivers.
> 
> I think saying that there is no infrastructure for writing Rust drivers is not
> accurate:
> 
> We already have lots of infrastructure in place, such as device / driver core
> infrastructure, PCI, platform (with OF and ACPI), faux and auxilirary bus
> infrastructure, I/O, workqueues, timekeeping, cpufreq, firmware, DMA and a lot
> more.
> 
> Not to forget the absolute core primitives, such as kernel allocators, xarray,
> locking infrastructure or very recently maple tree and LKMM atomics.
> 
> Besides that we also have a lot of infrastructure that we do not have in C
> because it's simply not possible or applicable.
> 
> However, it is in fact true that there is no USB infrastructure yet.

Ah yes, of course there’s plenty of things but this is specifically about
USB. I worked on a few of those so I'm not denying them, I guess I should have
written this more clearly :)

I’ve also been told the same about media drivers. For example, someone
trying to write a USB media driver stares at work needed to just _start_ doing
what they had initially planned and simply gives up. It creates a scenario
where people continuously wait on each other to do the "heavy work", i.e.: to
come up with the common code/abstractions.

So far I see a pattern where sample drivers count as users. This has been the
case, for example, for rust_dma.rs. I was under the impression that the same
would apply here. Although I do realize that there were plans for dma code
other than rust_dma.rs, of course.

> 
>> It's a chicken and egg problem that I am trying to solve.
> 
> This is exactly why we develop Nova in-tree, such that we have a justification
> for adding all this infrastructure.
> 
> Lot's of the stuff I listed above originates from that and I think the Nova
> project has proven that we can break this chicken and egg problem. I think
> one proof for that is that Tyr follows the approach.
> 
> However, I agree that it still remains that someone (i.e. some driver) has to
> take the burden of doing the "heavy lifting" for a particular subsystem.

As for Nova and Tyr, these are projects with a lot of big companies involved.

They were able to break this chicken and egg situation in part due to that,
because companies were willing to allocate engineers for both the drivers _and_
the required infrastructure. Unless the same can be said for USB, media or any
other subsystems, I don't see it happening. Also, even if there is a company
interested, smaller ones are not willing to work on the infrastructure either,
only on the actual end results (i.e.: drivers).

That's just my humble opinion, of course.