Quoting Elad Efrat <elad@NetBSD.org>:

> 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