Re: [RFC PATCH 2/4] rust: usb: add usb host interface and endpoint abstractions

[Alan Stern]

On Tue, Jul 14, 2026 at 03:05:16PM +0200, Danilo Krummrich wrote:
> On Tue Jul 14, 2026 at 11:26 AM CEST, Oliver Neukum wrote:
> > You can see that there is no way a configuration and thereby its interfaces
> > can last longer than its device.
> 
> So, what you're saying is that, in the generic case, there is a guarantee that
> if a usb_interface is bound to a usb_driver, then the usb_interface's parent
> usb_device is also bound to a usb_device_driver.

At first I thought that we ought to have such a guarantee.  But in fact 
we don't, because the user can at any time write to a USB device's 
bConfigurationValue sysfs attribute even if the device isn't bound to a 
driver.  This can create interfaces which may then be bound to drivers.  
I just tried it and it worked.

This wasn't the original intent, but I don't see any good reason to 
prevent people from doing it.

> But the relevant question is whether this always holds. In a previous discussion
> [1] Alan explained that it currently doesn't hold.
> 
> Note that I'm not looking at this from a USB topology perspective, but from a
> driver model perspective. All I'm saying is that usb::Device<Bound> from the
> driver model side means "it is guaranteed that the usb_device is bound to a
> usb_device_driver" and therefore can implement functions that rely on this
> invariant.

I don't see why Rust needs to distinguish between a USB device that is 
bound and one that is unbound.  There isn't much you can do with one 
that can't be done with the other.

> Analogously, usb::Interface<Bound> means that the usb_interface is bound to a
> usb_driver. So, if we want to be able to derive usb::Device<Bound> from
> usb::Interface<Bound> it must always be guaranteed that this holds, not just in
> the most common case.

Similarly, I don't see why Rust needs to distinguish between an 
interface that is bound and one that isn't.

Even from the point of view of the device core, a device that is bound 
to a driver is the same kind of data structure as one that isn't bound; 
the only difference is whether the ->driver pointer is set.

I'm aware that Rust has separate types for pointers that may be NULL and 
pointers that cannot be NULL.  Putting that into the language helps 
prevent a lot of bugs.  How would making the language be aware of 
whether a device is bound to a driver be similarly useful?

Alan Stern