Yes, but people already expect to run depmod at boot, and I haven't
made depmod safe for cross compiling. It could be done, but is it
worth it? I don't know.
BTW, the reason for using the alias mechanism is that aliases are
useful in themselves: consider you write a "new_foo" driver, you can
do "MODULE_ALIAS("foo")" and so no userspace changes are neccessary.
module-init-tools 0.9.8 already supported this.
> 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.
OK. Fortunately I have a new version of the table2alias program which
takes the elf object directly, anyway, which has the benifit of being
faster, too.
> 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.
Great minds think alike: this was what Greg said. I did this in the
updated patch.
> 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).
I prefer to keep special symbols out of section names, so we can do
nice tricks later with __start_. So __discard_modalias would be my
preference if we're going to change it.
> o I'm not totally happy with the integration into the build system yet,
> but it'll clash with the module versioning changes anyway ;)
Yeah, I thought you'd say that 8). I consider this to be after
modversions in the queue, and I don't want to overload you.
> 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.
Well, you get them as warnings from depmod, but more timely checks is
good.
> 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.
We can already figure what symbols it uses in depmod: the original
modprobe did just that, but Adam Richter complained about speed with
1200 modules (sure, it's < 1 second for most people, but Debian on an
old 486 would suck hard).
But putting the dependent module names in a section... I must say I
rather like that. I'll have to mull it over though.
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/