On Fri, 31 Jan 2003, Roman Zippel wrote:
> 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
What you say is right (except that it misses symbols exported from
modules), but I don't see what you mean the problem is?
> 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.
Well, I hope you mean into the kernel tree, it sure doesn't make sense to
put it into the kernel itself.
Anyway, I think rusty's approach is to deal with the kernel-internal data
structures from inside the kernel tree (during the build, that is) and
generate data in a fixed format (.modalias) for depmod to read. Since
depmod is external, it needs a fixed interface. Makes sense to me.
--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:27 EST