On Wed, Dec 11, 2024 at 2:31 PM Danilo Krummrich <dakr@xxxxxxxxxx> 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. Alice
