netdev - Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Nov 2007 19:03:04 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andi Kleen <ak@...e.de>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	sam@...nborg.org, rusty@...tcorp.com.au
Subject: Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Thu, 22 Nov 2007 03:43:06 +0100 (CET)
Andi Kleen <ak@...e.de> wrote:

> 
> There seems to be rough consensus that the kernel currently has too
> many exported symbols. A lot of these exports are generally usable
> utility functions or important driver interfaces; but another large
> part are functions intended by only one or two very specific modules
> for a very specific purpose. One example is the TCP code. It has most
> of its internals exported, but only for use by tcp_ipv6.c (and now a
> few more by the TCP/IP congestion modules) But it doesn't make sense
> to include these exported for a specific module functions into a
> broader "kernel interface".   External modules assume they can use
> these functions, but they were never intended for that.
> 
> This patch allows to export symbols only for specific modules by 
> introducing symbol name spaces. A module name space has a white
> list of modules that are allowed to import symbols for it; all others
> can't use the symbols.
> 
> It adds two new macros: 
> 
> MODULE_NAMESPACE_ALLOW(namespace, module);
> 
> Allow module to import symbols from namespace. module is the module
> name without .ko as displayed by lsmod.  Must be in the same module
> as the export (and be duplicated if there are multiple modules
> exporting symbols to a namespace).  Multiple allows for the same name
> space are allowed.
> 
> EXPORT_SYMBOL_NS(namespace, symbol);
> 

Hi,

I like this concept in general; I have one minor comment; right now
your namespace argument is like

EXPORT_SYMBOL_NS(foo, some_symbol);

from a language-like pov I kinda wonder if it's nicer to do

EXPORT_SYMBOL_NS("foo", some_symbol);

because foo isn't something in C scope, but more a string-like
identifier...



-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html