Hi,
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:
bus=usb
vendor=0x1234
product=0x4321
device=1-3,5
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.
bye, Roman
-
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:26 EST