Re: [PATCH v4 00/27] rust: device: Higher-Ranked Lifetime Types for device drivers

[Greg KH]

On Fri, May 22, 2026 at 01:34:26AM +0200, Danilo Krummrich wrote:
> Currently, Rust device drivers access device resources such as PCI BAR mappings
> and I/O memory regions through Devres<T>.
> 
> Devres::access() provides zero-overhead access by taking a &Device<Bound>
> reference as proof that the device is still bound. Since a &Device<Bound> is
> available in almost all contexts by design, Devres is mostly a type-system level
> proof that the resource is valid, but it can also be used from scopes without
> this guarantee through its try_access() accessor.
> 
> This works well in general, but has a few limitations:
> 
>   - Every access to a device resource goes through Devres::access(), which
>     despite zero cost, adds boilerplate to every access site.
> 
>   - Destructors do not receive a &Device<Bound>, so they must use try_access(),
>     which can fail. In practice the access succeeds if teardown ordering is
>     correct, but the type system can't express this, forcing drivers to handle a
>     failure path that should never be taken.
> 
>   - Sharing a resource across components (e.g. passing a BAR to a sub-component)
>     requires Arc<Devres<T>>.
> 
>   - Device references must be stored as ARef<Device> rather than plain &Device
>     borrows.
> 
> These limitations stem from the driver's bus device private data being 'static
> -- the driver struct cannot borrow from the device reference it receives in
> probe(), even though it structurally cannot outlive the device binding.
> 
> This series introduces Higher-Ranked Lifetime Types (HRT) for Rust device
> drivers. An HRT is a type that is generic over a lifetime -- it does not have a
> fixed lifetime, but can be instantiated with any lifetime chosen by the caller.
> 
> Bus driver traits use a Generic Associated Type (GAT) type Data<'bound> to
> introduce the lifetime on the private data, rather than parameterizing the
> Driver trait itself. This avoids a driver trait global lifetime and avoids the
> need for ForLt for bus device private data, making the bus implementations much
> simpler. ForLt is only needed for auxiliary registration data, where the
> lifetime is not introduced by a trait callback but must be threaded through
> Registration.
> 
> With HRT, driver structs carry a lifetime parameter tied to the device binding
> scope -- the interval of a bus device being bound to a driver. Device resources
> like pci::Bar<'bound> and IoMem<'bound> are handed out with this lifetime, so
> the compiler enforces at build time that they do not escape the binding scope.
> 
> Before:
> 
> 	struct MyDriver {
> 	    pdev: ARef<pci::Device>,
> 	    bar: Devres<pci::Bar<BAR_SIZE>>,
> 	}
> 
> 	let io = self.bar.access(dev)?;
> 	io.read32(OFFSET);
> 
> After:
> 
> 	struct MyDriver<'bound> {
> 	    pdev: &'bound pci::Device,
> 	    bar: pci::Bar<'bound, BAR_SIZE>,
> 	}
> 
> 	self.bar.read32(OFFSET);
> 
> Lifetime-parameterized device resources can be put into a Devres at any point
> via Bar::into_devres() / IoMem::into_devres(), providing the exact same
> semantics as before. This is useful for resources shared across subsystem
> boundaries where revocation is needed.
> 
> This also synergizes with the upcoming self-referential initialization support
> in pin-init, which allows one field of the driver struct to borrow another
> during initialization without unsafe code.
> 
> The same pattern is applied to auxiliary device registration data as a first
> example beyond bus device private data. Registration<F: ForLt> can hold
> lifetime-parameterized data tied to the parent driver's binding scope. Since the
> auxiliary bus guarantees that the parent remains bound while the auxiliary
> device is registered, the registration data can safely borrow the parent's
> device resources.
> 
> More generally, binding resource lifetimes to a registration scope applies to
> every registration that is scoped to a driver binding -- auxiliary devices,
> class devices, IRQ handlers, workqueues.
> 
> A follow-up series extends this to class device registrations, starting with
> DRM, so that class device callbacks (IOCTLs, etc.) can safely access device
> resources through the separate registration data bound to the registration's
> lifetime without Devres indirection.
> 
> The series contains a few driver patches for reference, indicated by the REF
> suffix.
> 
> Thanks to Gary for coming up with the ForLt implementation; thanks to Alice for
> the early discussions around lifetime-parameterized private data that helped
> shape the direction of this work.

Looks nice!

Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>