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. > 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.
