Message-Id: <85B643A9-1657-43ED-BE98-BE7E502D08DA@collabora.com>
Date: Sat, 6 Sep 2025 12:46:20 -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>,
 Michal Wilczynski <m.wilczynski@...sung.com>,
 Igor Korotin <igor.korotin.linux@...il.com>,
 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



> On 6 Sep 2025, at 12:22, Danilo Krummrich <dakr@...nel.org> wrote:
> 
> On Sat Sep 6, 2025 at 4:50 PM CEST, Daniel Almeida wrote:
>> 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.
> 
> This isn't the case, we have those sample drivers to make it easy to review the
> the code and illustrate in an isolated context how it works. But, there has
> always been a "real" user behind that. In the case of the DMA work it was Nova.

I see, thanks for clarifying!

> 
>> 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.
> 
> Well, this is true for Nova and Tyr, but I disagree that this is the reason we
> were able to break the chicken and egg problem.
> 
> For instance, the initial lift around the driver core, PCI, I/O, etc.
> infrastructure was done by me, a single person. This could have been happening
> in the context of a very simple and small driver as well, rather than a big GPU
> driver with lots of companies and people involved.
> 
> Igor (Cc) is doing the initial lift for I2C and Michal (Cc) for PWM for
> instance.
> 
> So, I see those things happen and I don't think that such initial lifting
> necessarily needs big companies with dozens of engineers being involved.

It’s not about the number of people, or the work being out of reach for a
single person, but more of someone asking themselves why it should be them to
do it when there’s no big project like Nova or Tyr to justify it and employ
them to do it all, vs employ them only for the actual drivers but not for the
abstractions. Or if they’re working on their free time, it becomes even
harder to justify spending energy on the abstractions if all they want is
to write a driver.

But if anyone got the impression that it is impossible to do it, my bad. It
isn’t.

> 
> If we know people who want to write drivers for a subsystem that doesn't yet
> have Rust infrastructure (such as USB), let's encourage them to get started /
> involved anyways and let's help them as they go.
> 
> But also please don't get me wrong, I understand and very much appreciate you
> want to get the ball rolling, but let's not discourage people by making it
> sounds as if it would be impossible for individuals.
> 

Yeah, point taken :)

As I said to Greg above, I’m here to help if anyone wants to write a USB
driver. Those interested are free to reach out to me and we will work together
to merge the required abstractions with a real user in mind. Hopefully this
encourages others to join in this work :)


— Daniel

Powered by blists - more mailing lists