Re: [PATCH v2 1/2] rust: introduce abstractions for fwctl

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Jan 27, 2026 at 09:07:37PM +0100, Danilo Krummrich wrote:
> On Tue Jan 27, 2026 at 8:57 PM CET, Zhi Wang wrote:
> > The fwctl_alloc_device() helper allocates a raw struct fwctl_device
> > without private driver data here. The Rust driver object should be
> > already allocated and initialized separately before reaching this
> > point.
> >
> > We rely on the standard dev->parent chain to access the rust driver
> > object from the fwctl callbacks.
> 
> (I will go for a thorough review soon, but for now a quick drive-by comment.)
> 
> IIUC, you are saying that the user is supposed to use the private data of the
> parent device in fwctl callbacks. Let's not make this a design choice please.
> Instead, allow the user pass in separate private data for the fwctl device as
> well.
> 
> This serves the purpose of clear ownership and lifetime of the data. E.g. the
> fwctl device does not necessarily exist as long as the parent device is bound.
> 
> It is a good thing if driver authors are forced to take a decision about which
> object owns the data and what's the scope of the data.

I'm not sure what the model is in rust, but the expection here is for
the driver to have a window between alloc and register where the
driver can fill in any information into the core structures that is
needed before calling registration.

Think like the driver core - the end user needs to be able to call
dev_name() (and lots of others!) after device_initialize() but before
calling register/add.

I don't think we use this right now in fwctl, but I'd rather it not be
erased from the rust bindings entirely. That sounds hard to unwind
someday.

This is pretty common subsystem design so I'd think there should be a
general pattern in rust as well?

Jason