Re: [PATCH v5 01/16] rust: pass module name to `Module::init`

[Danilo Krummrich <dakr@kernel.org>]

On Wed, Dec 11, 2024 at 04:36:35PM +0100, Danilo Krummrich wrote:
> On Wed, Dec 11, 2024 at 04:15:19PM +0100, Alice Ryhl wrote:
> > On Wed, Dec 11, 2024 at 4:03 PM Danilo Krummrich <dakr@kernel.org> wrote:
> > >
> > > On Wed, Dec 11, 2024 at 03:55:47PM +0100, Alice Ryhl wrote:
> > > > On Wed, Dec 11, 2024 at 3:52 PM Danilo Krummrich <dakr@kernel.org> wrote:
> > > > >
> > > > > On Wed, Dec 11, 2024 at 03:45:53PM +0100, Alice Ryhl wrote:
> > > > > > On Wed, Dec 11, 2024 at 3:29 PM Danilo Krummrich <dakr@kernel.org> wrote:
> > > > > > >
> > > > > > > On Wed, Dec 11, 2024 at 02:34:54PM +0100, Alice Ryhl wrote:
> > > > > > > > On Wed, Dec 11, 2024 at 2:31 PM Danilo Krummrich <dakr@kernel.org> 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.
> > > > > > > > >
> > > > > > > > > I think we could avoid having an additional `name` parameter in `Module::init`,
> > > > > > > > > but it would still need to be the driver resolving `env!(KBUILD_MODNAME)`
> > > > > > > > > passing it into the bus abstraction.
> > > > > > > > >
> > > > > > > > > However, similar to what Alice suggested in another thread, we could include
> > > > > > > > > this step in the `module_*_driver!` macros.
> > > > > > > > >
> > > > > > > > > Modules that don't use this convenience macro would need to do it by hand
> > > > > > > > > though. But that's probably not that big a deal.
> > > > > > > >
> > > > > > > > I think we can do it in the core `module!` macro that everyone has to use.
> > > > > > >
> > > > > > > How? The `module!` macro does not know about the registration instances within
> > > > > > > the module structure.
> > > > > >
> > > > > > You could have the module! macro emit something along these lines:
> > > > > >
> > > > > > impl ModuleName for {type_} {
> > > > > >     const NAME: &'static CStr = c_str!(env!("KBUILD_MODNAME"));
> > > > > > }
> > > > > >
> > > > > > Then you can do `<Self as ModuleName>::NAME` to obtain the name elsewhere.
> > > > >
> > > > > Where {type_} would need to be the driver's `Driver` structure?
> > > > >
> > > > > We'd then need to define the bus adapter as:
> > > > >
> > > > > `pub struct Adapter<T: Driver + ModuleName>(T)`
> > > > >
> > > > > But the question stands I guess, how would the module macro know {type_}?
> > > >
> > > > If you look at the macro implementation in rust/macros/module.rs you
> > > > will find many uses of {type_} throughout the expansion. It's whatever
> > > > is passed to the macro using the `type:` argument.
> > >
> > > Oh, I see. So, this means that module / driver author would still need to create
> > > the "connection" by listing the correspong driver types in the module! macro,
> > > right?
> > 
> > I'm not sure what you mean. I'm *not* suggesting any changes to the
> > interface of module! or module_*_driver!.
> 
> Huh! Seems like we're talking past each other than. Maybe we can briefly
> discuss it in today's call?

I think I figured out the confusion.

The {type_} in the module macro is the thing that implements the `Module` or
`InPlaceModule` trait. However, that's *not* the driver type that is embedded in
the bus adapter.

For instance, what we have is:

```
struct MyDriver;

struct MyModule {
   _driver: Registration<pci::Adapter<MyDriver>,
};

impl pci::Driver for MyDriver { ... }

impl InPlaceModule for MyModule { ... }

module! {
   type: MyModule,
   ...
}
```

This means `module!` would generate:

`impl ModuleName for MyModule { ... }`

But this doesn't help, because `pci::Adapter` doesn't know about `MyModule`, but
only about `MyDriver`.

Do I miss anything?

> 
> > 
> > > If so, I think it'd be better to do it in the `module_*_driver!` macro and let
> > > people implement the trait by hand for modules with multiple drivers (which
> > > should be pretty rare).
> > >
> > > The reason is that I think that otherwise we're probably encoding too much
> > > semantics into the `module!` macro that isn't obvious and people need to
> > > understand.
> > >
> > > >
> > > >
> > > > Alice