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.
- 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? Though I think there is value in doing the same
thing for symbol namespaces: right now, the only way to find out if
all modules correctly import a symbol exported to a namespace is to
run an 'allmodconfig'; not having to do that would be a win. Being
able to do the same thing for the exported symbols in the global
namespace is very similar. So yeah, I think this is a good idea and
will look into this more.
Do you think these things should be a part of these series, or can it
be a follow-up?
Thanks,
Martijn
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
