> This underscore vs. hyphen thing is terrible.

Yeah.  But looking at kmod, it doesn't seem to be so bad for them.

They basically always use the version with underscores as the lookup
key for their internal hash tables.

For alias resolving, they use a resolver for [a-zxxx] AND they replace
dashes THAT ARE NOT IN THE "[...]" block by underscore before using it
for lookups.

modules.dep entries are always file names (no replacements whatsoever).

When a module is loaded as a result of an alias lookup, it has a special
key (string-append name "\" target-alias).  No idea what that's for.

I'd caution about complicating our version overly much by putting
just-in-case replacements everywhere.  Rather we should find out what
their original strategy is (if any :P) and do that as well.

Module aliases (the alias itself, not what it's resolved to) sometimes look
like that:

./arch/x86/crypto/des3_ede_glue.c:MODULE_ALIAS_CRYPTO("des3_ede-asm");

WTF...

But the thing the alias is resolved to is always the modname (which
has hyphens replaced by underscore and stops before a dot).

Their bin files (we don't use them) always have the final modname as key,
as opposed to their source files (for example "modules.alias" rather
than "modules.alias.bin").  (The source files sometimes have paths as key)

I think that they assume that each module, whether it has dependencies or
not, is listed in modules.dep .  They use modules.dep.bin for the lookup
of a module by modname, rather than by path.

So I think a pretty good fix is:

Every time we want to lookup a module by modname, check a hashtable that
is built from modules.dep by:
 
* let x-path be the first value of each modules.dep line.
* Then the key for the hashtable entry is (underscore (stop-at-dot (basename x-path)))
* And the value for the hashtable entry is x-path.

In this way we would look up modules in a way similar to them.

Why they couldn't just have used file names without mangling them beats me.
Sigh...