On Fri, 31 Jan 2003, Rusty Russell wrote:
> This patch adds MODULE_ALIAS("foo") capability, and uses it to
> automatically generate sensible aliases from device tables. The
> post-processing is a little rough, but works.
>
> Name: Module alias and device table support
> Author: Rusty Russell
> Status: Tested on 2.5.59
>
> D: Introduces "MODULE_ALIAS" which modules can use to embed their own
> D: aliases for modprobe to use. Also adds a "finishing" step to modules to
> D: supplement their aliases based on MODULE_TABLE declarations, eg.
> D: 'usb:v0506p4601dl*dh*dc*dsc*dp*ic*isc*ip*' for drivers/usb/net/pegasus.o
Some comments:
o First of all, we're basically moving depmod functionality into the
kernel tree, which I regard as a good thing, since we have to deal
with actual kernel structures here. (The obvious disadvantage is that
this makes it much easier to change these kernel structures, which
breaks compatibility with other (user space) tools who expect a certain
format)
I was wondering if it's not somewhat kludgy to add info into an ELF
section into a module, just to have it extracted again by modutils
shortly afterwards - the alternative would be to have the kernel
generate modules.*map directly (or rather modules.alias now).
However, I guess I'm convinced now that this is per-module information
and should be kept as such. To avoid all kinds of trouble with separate
files (module.ko and module.alias), it's probably really best to store
it into an elf section directly.
o My nm (RH 7.2 or .3, GNU nm 2.11.90.0.8) doesn't support --print-size.
That'll probably affect many users.
o What about collecting the struct xxx_device_id definitions into some
header which could be included from the userspace code extracting
the info instead of duplicating it. Still not quite fool-proof, but
better than duplicating the info.
o I think it'd be a good time to consider naming these sections e.g.
"__discard.modalias", the license one "__discard.license" and have
the kernel module loader discard "__discard*", so that it doesn't
need to be aware of all that special crap, nor waste space for it.
(Well, it needs to know about the license, anyway, so that's not such
a good example).
o I'm not totally happy with the integration into the build system yet,
but it'll clash with the module versioning changes anyway ;)
The modversions patch introduces a postprocessing stage for modules, which
currently will only be invoked with CONFIG_MODVERSIONS set. However, I'm
considering to make that pass mandatory either way. It basically obtains
the list of all modules from the earlier stage, so it doesn't recurse and
can thus be very fast. I'm currently coding the actual versioning process
in C, since the shell / sed / grep based solution's performance isn't
exactly great. In doing that, I already notice unresolved symbols and warn
about them, which I think is an improvement to the build process, missing
EXPORT_SYMBOL()s tend to go unnoticed quite often otherwise.
Doing this postprocessing unconditionally would allow to generate the
alias tables at this point as well.
And while we're at it, we could add another section which specifies which
other modules this module depends on (a.k.a which symbols it uses), making
depmod kinda obsolete.
--Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 31 2003 - 22:00:25 EST