linux-kernel - Re: [PATCH v2 1/2] rust: introduce abstractions for fwctlg

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: <20260128163927.GD1134360@nvidia.com>
Date: Wed, 28 Jan 2026 12:39:27 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Zhi Wang <zhiw@...dia.com>, rust-for-linux@...r.kernel.org,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	aliceryhl@...gle.com, bhelgaas@...gle.com, kwilczynski@...nel.org,
	ojeda@...nel.org, alex.gaynor@...il.com, boqun.feng@...il.com,
	gary@...yguo.net, bjorn3_gh@...tonmail.com, lossin@...nel.org,
	a.hindborg@...nel.org, tmgross@...ch.edu, markus.probst@...teo.de,
	helgaas@...nel.org, cjia@...dia.com, smitra@...dia.com,
	ankita@...dia.com, aniketa@...dia.com, kwankhede@...dia.com,
	targupta@...dia.com, acourbot@...dia.com, joelagnelf@...dia.com,
	jhubbard@...dia.com, zhiwang@...nel.org,
	daniel.almeida@...labora.com
Subject: Re: [PATCH v2 1/2] rust: introduce abstractions for fwctlg

On Wed, Jan 28, 2026 at 05:35:04PM +0100, Danilo Krummrich wrote:
> On Wed Jan 28, 2026 at 4:56 PM CET, Jason Gunthorpe wrote:
> > On Wed, Jan 28, 2026 at 04:49:07PM +0100, Danilo Krummrich wrote:
> >
> >> 	        // Initialize the `data` initializer within the memory pointed
> >> 	        // to by `raw_data`.
> >> 	        unsafe { data.__pinned_init(raw_data) }.inspect_err(|_| {
> >
> >> So, essentially the driver passes an initializer of its private data and we
> >> "write" this initializer into the extra memory allocated with
> >> _fwctl_alloc_device().
> >
> > This all seems like the right way to do it!
> >
> > My only remark it that it still doesn't give an opportunity to call a
> > function between init and register.
> 
> You would, from a driver side it would look like this:
> 
> 	#[pin_data]
> 	struct MyDriver {
> 	    #[pin]
> 	    _reg: Devres<fwctl::Registration>,
> 	    fwctl: ARef<fwctl::Device>,
> 	}
> 
> 	#[pin_data]
> 	struct FwctlData {
> 	    #[pin]
> 	    foo: Mutex<Foo>,
> 	    ...,
> 	}
> 
> 	impl pci::Driver for MyDriver {
> 	    fn probe(
> 	        pdev: &pci::Device<Core>,
> 	        _info: &Self::IdInfo,
> 	    ) -> impl PinInit<Self, Error> {
> 	        let fwctl = fwctl::Device::new(
> 	            pdev.as_ref(),
> 	            try_pin_init!(FwctlData {
> 	                foo <- mutex_new!(Foo::new()),
> 	                ...,
> 	            }),
> 	        )?;
> 
> 	        // Let's do something with the `fwctl::Device` before we
> 	        // register it.
> 	        fwctl.do_stuff();
> 
> 	        try_pin_init!(Self {
> 	            // We could omit this and instead provide
> 	            // `fwctl::Registration::register()`, which does only return
> 	            // a `Result` and keeps the `fwct::Device` registered until
> 	            // driver unbind.
> 	            _reg <- fwctl::Registration::new(pdev.as_ref(), fwctl);
> 	            fwctl,
> 	        })
> 	    }
> 	}

Okay it is fine by me, Zi did you get all this?

Jason