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
| ||
|
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
Powered by blists - more mailing lists