Quoting Elad Efrat <elad%NetBSD.org@localhost>:
Antti Kantee wrote:On Thu Jan 17 2008 at 22:32:49 +0000, Stephen M. Rumble wrote:Module Name: src Committed By: rumble Date: Thu Jan 17 22:32:49 UTC 2008 Modified Files: src/sys/kern: subr_kobj.c Log Message: Before bailing on ENOENT, try one more time with an appended ".o". This lets us load dependencies by module name and makes 'modload foo' work when 'foo.o' is the file.Is this a policy decision the kernel should be making?No. Please revert this. I only know of one other case the kernel used to do this, and it was a design flaw...
The kernel already makes a policy decision, namely, upon failing to load the file (assuming first it's a full path), it prefixes "/modules/" and tries again. It's a bit hacky, yes, but adding another guess isn't exactly without precedent.
I didn't like the solution, either, but I'm not sure what the best way to approach it is given that the kernel presently resolves dependencies itself. If it is to do so, and if we are to name module files "MODNAME.o" and refer to the modules everywhere else as "MODNAME", then what choice do we have?
It'd be nicest to have modload handle dependencies and do all of the guesswork as to which file corresponds to which module name, but I'm not sure whether dependency resolution in the kernel would still be desirable or not.
I'm happy to remove my own and the pre-existing guesswork in kobj_open, but only in light of a better solution, as I don't see it being any worse than it used to be.
Steve