[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071123195330.GA24223@one.firstfloor.org>
Date: Fri, 23 Nov 2007 20:53:30 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Rusty Russell <rusty@...tcorp.com.au>
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 Fri, Nov 23, 2007 at 02:35:05PM +1100, Rusty Russell wrote:
> On Friday 23 November 2007 12:36:22 Andi Kleen wrote:
> > On Friday 23 November 2007 01:25, Rusty Russell wrote:
> > > That's my point. If there's a whole class of modules which can use a
> > > symbol, why are we ruling out external modules?
> >
> > The point is to get cleaner interfaces.
>
> But this doesn't change interfaces at all. It makes modules fail to load
> unless they're on a permitted list, which now requires maintenance.
The modules wouldn't be using the internal interfaces in the first
place with name spaces in place. 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.
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.
Another secondary reason is that there are too many exported interfaces
in general. 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.
-Andi
-
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/
Powered by blists - more mailing lists