lkml.org 
[lkml]   [2018]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 0/6] Symbol namespaces
On Mon, Jul 16, 2018 at 2:21 PM, Martijn Coenen <maco@android.com> wrote:
> As of Linux 4.17, there are more than 30000 exported symbols
> in the kernel. There seems to be some consensus amongst
> kernel devs that the export surface is too large, and hard
> to reason about.
>
> Generally, these symbols fall in one of these categories:
> 1) Symbols actually meant for drivers
> 2) Symbols that are only exported because functionality is
> split over multiple modules, yet they really shouldn't
> be used by modules outside of their own subsystem
> 3) Symbols really only meant for in-tree use
>
> When module developers try to upstream their code, it
> regularly turns out that they are using exported symbols
> that they really shouldn't be using. This problem is even
> bigger for drivers that are currently out-of-tree, which
> may be using many symbols that they shouldn't be using,
> and that break when those symbols are removed or modified.
>
> This patch allows subsystem maintainers to partition their
> exported symbols into separate namespaces, and module
> authors to import such namespaces only when needed.
>
> This allows subsystem maintainers to more easily limit
> availability of these namespaced symbols to other parts of
> the kernel. It can also be used to partition the set of
> exported symbols for documentation purposes; for example,
> a set of symbols that is really only used for debugging
> could be in a "SUBSYSTEM_DEBUG" namespace.

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. 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.

- 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).

Arnd

\
 
 \ /
  Last update: 2018-07-23 16:29    [W:0.891 / U:31.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site