lkml.org 
[lkml]   [2007]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
Date
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-11-24 05:57    [W:0.168 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site