mii module broken under new scheme
Quoted 16 lines · Matt Reppert
Quoted 8 lines · On Tue, 19 Nov 2002 12:51:44 -0500 Jeff Garzik <[email protected]> wrote:
Quoted 5 lines · Matt Reppert
drivers/net/mii.cdoesn't export module init/cleanup functions. That means it
can't be loaded under the new module scheme. This patch adds do-nothing functions for it, which allows it to load. (8139too depends on mii, so without this I don't have network.)Quoted 4 lines
ahhh! I was wondering what was up, but since I was busy with other
things I just compiled it into the kernel and continued on my way.That's a bug in the new module loader.
Quoted 8 lines
Not so sure I agree ... recompiled the kernel with debugging output in
module.cand when I try to insert mii.o without above patch it complains "Module has no name!" and returns-ENOEXECfrom the syscall. I think naming mii.o would be a good idea. This may not be the best way to do it, but it works. (Granted, I'm not terribly familiar with all the modules code changes yet, but ... ) Having anonymous output in lsmod would be somewhat confusing :) ("Well, whatever it is, 8139too needs it, don't touch it!")
I think that retrieving module name from module's binary is wrong: I need to have dummy.o (network driver) insmodded two times to get my test environment up.
I do not think that it is correct that I must add multiple device support to the dummy due to new module loader, and creating two dummy.o, with different .modulename sections, also does not look like reasonable solution to me.
Best regards,
Petr Vandrovec [email protected]
Quoted 3 lines · Petr Vandrovec
I think that retrieving module name from module's binary is wrong: I need to have dummy.o (network driver) insmodded two times to get my test environment up.
agreed... this requirement is why the redundant no_module_init is needed :(
Quoted 4 lines
I do not think that it is correct that I must add multiple device support to the dummy due to new module loader, and creating two dummy.o, with different .modulename sections, also does not look like reasonable solution to me.
The promise of minimal driver breakage is rapidly fading away.
Jeff, still grumbling from last email message :)
In message <[email protected]> you write:
Quoted 1 line
The promise of minimal driver breakage is rapidly fading away.
Perhaps: but this, at least, is being fixed by having a "finishing" step for modules. And it *did* catch three "modules" that weren't really, so it's not completely useless.
Think back: who in their right mind would compile and test patches to a rapidly-changing kernel, when those changes required userspace tool changes and you didn't know if it was going to go in or not? If you care about modules in 2.5, you're probably a developer who needs modules to do their job, so why rock the boat?
So I had to make a number of judgement calls without *any* input from anyone else. This was one: change the makefiles to add an extra step, or require modules to say "I really am a module, not some random object file".
On the one hand I've been trying to feed this to Linus slowly so that *now* lkml can give feedback, on the other hand, fend of those who are complaining that their needed feature isn't back in yet.
You've seen some of my decisions reversed already: noone wishes more than me this had happened months ago 8(
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
In message <[email protected]> you write:
Quoted 8 lines
I think that retrieving module name from module's binary is wrong: I need to have dummy.o (network driver) insmodded two times to get my test environment up.
I do not think that it is correct that I must add multiple device support to the dummy due to new module loader, and creating two dummy.o, with different .modulename sections, also does not look like reasonable solution to me.
Doing this based on module name has been deprecated basically forever, because it doesn't work *at all* when you build it into the kernel. The reason that modules know their own name is that boot parameters are called by it.
Four possible solutions:
1) Fix dummy to be a real device driver.
2) Add a module parameter to set the device name on dummy.o
3) Allow the build system to construct multiple modules.
4) Implement modprobe --rename.
If none of them appeals, we can discuss it.
Hope that helps,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.