On Fri, 31 Jan 2003, Kai Germaschewski wrote:
> 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.
The problem here is that we use System.map, it's not that difficult to
extract the exported symbols:
objcopy -j .kstrtab -O binary vmlinux .export.tmp
tr \\0 \\n < .export.tmp > Export.map
> 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.
It makes sense to keep depmod close to the linker, as both need the same
knowledge about resolving symbols, but I still don't know why that would
be a reason to put it into the kernel.
It doesn't really matter if that information is generated during build or
at install, it just has to be at /lib/module/`uname -r` in a way modprobe
understands. BTW for my taste modprobe has too much knowledge about the
module layout, which actually belongs to the linker.
I finally looked a bit closer at the module alias. The possibility of
wildcards is certainly interesting, but besides of this it looks to me as
if we exchange one crutch with another. The alias string is too static
and cryptic. Adding information to it requires changes at too many places
(let alone adding information dynamically).
What I'd really like to see is a really generic but still simple system to
match devices and drivers, e.g. describing properties like this:
Forcing the matching onto modprobe doesn't look like a good idea to me, as
IMO it takes too much away from hotplug. The alias string is not usable
for hotplug, but above properties can be used to trigger other operations
beside module loading.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/