Message-ID: <Z1mgATmU2WgYwCGZ@cassiopeiae>
Date: Wed, 11 Dec 2024 15:21:53 +0100
From: Danilo Krummrich <dakr@...nel.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: rafael@...nel.org, bhelgaas@...gle.com, ojeda@...nel.org,
	alex.gaynor@...il.com, boqun.feng@...il.com, gary@...yguo.net,
	bjorn3_gh@...tonmail.com, benno.lossin@...ton.me, tmgross@...ch.edu,
	a.hindborg@...sung.com, aliceryhl@...gle.com, airlied@...il.com,
	fujita.tomonori@...il.com, lina@...hilina.net, pstanner@...hat.com,
	ajanulgu@...hat.com, lyude@...hat.com, robh@...nel.org,
	daniel.almeida@...labora.com, saravanak@...gle.com,
	dirk.behme@...bosch.com, j@...nau.net, fabien.parent@...aro.org,
	chrisi.schrefl@...il.com, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH v5 01/16] rust: pass module name to `Module::init`

On Wed, Dec 11, 2024 at 02:45:14PM +0100, Greg KH wrote:
> On Wed, Dec 11, 2024 at 02:31:07PM +0100, Danilo Krummrich wrote:
> > On Wed, Dec 11, 2024 at 02:14:37PM +0100, Greg KH wrote:
> > > On Wed, Dec 11, 2024 at 01:34:31PM +0100, Danilo Krummrich wrote:
> > > > On Wed, Dec 11, 2024 at 01:22:33PM +0100, Danilo Krummrich wrote:
> > > > > On Wed, Dec 11, 2024 at 12:05:10PM +0100, Greg KH wrote:
> > > > > > On Wed, Dec 11, 2024 at 11:59:54AM +0100, Greg KH wrote:
> > > > > > > On Wed, Dec 11, 2024 at 11:48:23AM +0100, Greg KH wrote:
> > > > > > > > On Wed, Dec 11, 2024 at 11:45:20AM +0100, Greg KH wrote:
> > > > > > > > > On Tue, Dec 10, 2024 at 11:46:28PM +0100, Danilo Krummrich wrote:
> > > > > > > > > > In a subsequent patch we introduce the `Registration` abstraction used
> > > > > > > > > > to register driver structures. Some subsystems require the module name on
> > > > > > > > > > driver registration (e.g. PCI in __pci_register_driver()), hence pass
> > > > > > > > > > the module name to `Module::init`.
> > > > > > > > > 
> > > > > > > > > Nit, we don't need the NAME of the PCI driver (well, we do like it, but
> > > > > > > > > that's not the real thing), we want the pointer to the module structure
> > > > > > > > > in the register_driver call.
> > > > > > > > > 
> > > > > > > > > Does this provide for that?  I'm thinking it does, but it's not the
> > > > > > > > > "name" that is the issue here.
> > > > > > > > 
> > > > > > > > Wait, no, you really do want the name, don't you.  You refer to
> > > > > > > > "module.0" to get the module structure pointer (if I'm reading the code
> > > > > > > > right), but as you have that pointer already, why can't you just use
> > > > > > > > module->name there as well as you have a pointer to a valid module
> > > > > > > > structure that has the name already embedded in it.
> > > > > > > 
> > > > > > > In digging further, it's used by the pci code to call into lower layers,
> > > > > > > but why it's using a different string other than the module name string
> > > > > > > is beyond me.  Looks like this goes way back before git was around, and
> > > > > > > odds are it's my fault for something I wrote a long time ago.
> > > > > > > 
> > > > > > > I'll see if I can just change the driver core to not need a name at all,
> > > > > > > and pull it from the module which would make all of this go away in the
> > > > > > > end.  Odds are something will break but who knows...
> > > > > > 
> > > > > > Nope, things break, the "name" is there to handle built-in modules (as
> > > > > > the module pointer will be NULL.)
> > > > > > 
> > > > > > So what you really want is not the module->name (as I don't think that
> > > > > > will be set), but you want KBUILD_MODNAME which the build system sets.
> > > > > 
> > > > > That's correct, and the reason why I pass through this name argument.
> > > > > 
> > > > > Sorry I wasn't able to reply earlier to save you some time.
> > > > > 
> > > > > > You shouldn't need to pass the name through all of the subsystems here,
> > > > > > just rely on the build system instead.
> > > > > > 
> > > > > > Or does the Rust side not have KBUILD_MODNAME?
> > > > > 
> > > > > AFAIK, it doesn't (or didn't have at the time I wrote the patch).
> > > > > 
> > > > > @Miguel: Can we access KBUILD_MODNAME conveniently?
> > > > 
> > > > Actually, I now remember there was another reason why I pass it through in
> > > > `Module::init`.
> > > > 
> > > > Even if we had env!(KBUILD_MODNAME) already, I'd want to use it from the bus
> > > > abstraction code, e.g. rust/kernel/pci.rs. But since this is generic code, it
> > > > won't get the KBUILD_MODNAME from the module that is using the bus abstraction.
> > > 
> > > Rust can't do that in a macro somehow that all pci rust drivers can pull
> > > from?
> > 
> > The problem is that register / unregister is encapsulated within methods of the
> > abstraction types. So the C macro trick (while generally possible) isn't
> > applicable.
> 
> Really?  You can't have something in a required "register()" type function?
> Something for when the driver "instance" is created as part of
> pci::Driver?  You do that today in your sample driver for the id table:
> 	const ID_TABLE: pci::IdTable<Self::IdInfo> = &PCI_TABLE;
> 
> Something else called DRIVER_NAME that you could then set:
> 	const DRIVER_NAME: env!(KBUILD_MODNAME);

Sure, that's possible. But that means that the driver has to set it explicitly
-- even when e.g. module_pci_driver! is used.

In C you don't have that, because there it's implicit within the
pci_register_driver() macro. (Regardless of whether it's a single module for a
single driver or multiple drivers per module.)

Anyways, like I mentioned, given that we have `env!(KBUILD_MODNAME)` (which we
still need to add), there are other options to make it work similarly, e.g. add
a parameter to `pci::Adapter` and bake this into `module_pci_driver!`.

For this particular option, it would mean that for modules registering multiple
drivers a corresponding name would need to be passed explicitly.

> 
> Also, I think you will want this for when a single module registers
> multiple drivers which I think can happen at times, so you could
> manually override the DRIVER_NAME field.

My proposal above would provide this option, but do we care? In C no one ever
changes the name. There is zero users of __pci_register_driver(), everyone uses
pci_register_driver() where the name is just KBUILD_MODNAME. Same for
__platform_driver_register().

> 
> And if DRIVER_NAME doesn't get set, well, you just don't get the module
> symlink in sysfs, just like what happens today if you don't provide that
> field (but for PCI drivers, the .h file does it automatically for you.)
> 
> Anyway, this is a driver issue, NOT a module issue, so having to "plumb"
> the module name all the way down through this really isn't the best
> abstraction to do here from what I can tell.
> 
> thanks,
> 
> greg k-h

Powered by blists - more mailing lists