On Tue, Jul 24, 2018 at 10:09 AM, Martijn Coenen <maco@xxxxxxxxxxx> wrote: > Hi Arnd, > > On Mon, Jul 23, 2018 at 4:28 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> This looks nice. I don't want to overload you with additional >> requests, but it might be good to think about how this can >> be taken further, if we want to actually convert large >> parts of the kernel to it. > > No worries about overloading, I'm happy with all feedback to make this better. > >> I have two ideas: >> >> - It would be nice to have a simple mechanism in Kconfig >> to put all symbols in a module into a namespace that is >> derived from KBUILD_MODNAME, to avoid having to >> annotate every symbol separately. This could be similar >> to how we ended up dealing with EXPORT_NO_SYMBOLS >> in the linux-2.4 days, with the goal of eventually having >> a namespace for each symbol. Similarly, we could pass >> a number of default namespaces through the Makefile, >> e.g. if we have a directory that has lots of drivers that all >> import the symbols from a common subsystem module. > > I'm hinging on two thoughts here; I really like it because it > obviously reduces work and makes this easier to use. On the other > hand, you now have to look in multiple places to see if a symbol is > exported to a namespace/imported from a module. Perhaps it depends on > how coarse-grained the namespaces end up being. Either way, I think it > would be pretty easy to cook up patches for this. Ok, maybe try it and see where we get with it? >> - If this is possible to implement, it would be great to have >> a way to limit the globally visible symbols in a module >> to the ones that are explicitly exported even when a that >> module is built-in rather than loadable. Not sure how this >> is best done though. A couple of things can be done with >> objcopy, or possibly by reintroducing partial linking (which >> was removed not too long ago). > > If I understand you correctly, this is orthogonal to symbol > namespaces, right? Right, the only connection here is that both try to limit the scope of which symbols are available where. This can definitely be done without symbol namespaces. The implementation I had in mind with objcopy might end up using the same KBUILD_MODNAME as a prefix for internal symbols (which are not exported to modules), but that is a different problem. Another related area is the question what happens to symbols that we want to share between two built-in parts of the kernel without exporting them to modules. E.g. if we might want to put all of vfs into one built-in module and make its symbols private to that module, while all of the mm subsystem is in a separate built-in module. The symbols that are needed for communicating between the two could simply be exported with EXPORT_SYMBOL_GPL(), but we that would open the surface to loadable modules that can't access them today. Using namespaces could solve that problem by limiting the scope in another way, or we could come up with a different method to annotate them, such as using the gcc visibility attributes. > Do you think these things should be a part of these series, or can it > be a follow-up? If you think you can do the first thing easily, I'd say we should try to come up with an idea of where we want to take this in the long run. For limiting the scope of global symbols, that may well be a much bigger task to do upfront, so unless you have an idea for how to do that, maybe keep it in mind but let's not make it a dependency. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html