linux-kernel - 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 linux-cve-announce 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]

Message-Id: <200711241553.34744.rusty@rustcorp.com.au>
Date:	Sat, 24 Nov 2007 15:53:34 +1100
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Andi Kleen <ak@...e.de>, Christoph Hellwig <hch@...radead.org>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	sam@...nborg.org
Subject: Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Saturday 24 November 2007 06:53:30 Andi Kleen wrote:
> This serves as a documentation 
> on what is considered internal. And if some obscure module (in or
> out of tree) wants to use an internal interface they first have
> to send the module maintainer a patch and get some review this way.

So, you're saying that there's a problem with in-tree modules using symbols 
they shouldn't?  Can you give an example?

> I believe that is fairly important in tree too because the
> kernel has become so big now that review cannot be the only
> enforcement mechanism for this anymore.

If people aren't reviewing, this won't make them review.  I don't think the 
problem is that people are conniving to avoid review.

> Another secondary reason is that there are too many exported interfaces
> in general.

Probably, but this doesn't reduce it.  

> Several distributions have policies that require to 
> keep the changes to these exported interfaces minimal and that
> is very hard with thousands of exported symbol.  With name spaces
> the number of truly publicly exported symbols will hopefully
> shrink to a much smaller, more manageable set.

*This* makes sense.  But it's not clear that the burden should be placed on 
kernel coders.  You can create a list yourself.  How do I tell the difference 
between "truly publicly exported" symbols and others?

If a symbol has more than one in-tree user, it's hard to argue against an 
out-of-tree module using the symbol, unless you're arguing against *all* 
out-of-tree modules.

Sorry,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/