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: <2025090601-iron-glitter-c77d@gregkh>
Date: Sat, 6 Sep 2025 14:10:01 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Daniel Almeida <daniel.almeida@...labora.com>
Cc: 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>,
	Danilo Krummrich <dakr@...nel.org>, 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 Sat, Sep 06, 2025 at 09:04:04AM -0300, Daniel Almeida wrote:
> Hi Greg,
> 
> […]
> 
> > 
> > Sorry for the delay.
> > 
> > But these bindings really are only for a usb interface probe/disconnect
> > sequence, right?  no real data flow at all?
> > 
> > I recommend looking at the usb-skeleton.c driver, and implementing that
> > as your sample driver for rust.  That will ensure that you actually have
> > the correct apis implemented and the reference count logic working
> > properly.  You have urb anchors and callbacks and other stuff as well to
> > ensure that you get right.  That driver pretty much should handle
> > everything that you need to do to write a usb driver for any type of
> > "real" device.
> > 
> > thanks,
> > 
> > greg k-h
> 
> 
> 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