On Friday 30 November 2007 03:53:34 Arjan van de Ven wrote:
> On Mon, 26 Nov 2007 10:25:33 -0800
>
> > Agreed. On first glance, I was intrigued but:
> >
> > 1) Why is everyone so concerned that export symbol space is large?
> > - does it cost cpu or running memory?
>
> yes. about 120 bytes per
On Mon, 26 Nov 2007 10:25:33 -0800
>
> Agreed. On first glance, I was intrigued but:
>
> 1) Why is everyone so concerned that export symbol space is large?
> - does it cost cpu or running memory?
yes. about 120 bytes per symbol
> - does it cause bugs?
yes, bad apis are causing bugs
On Thursday 29 November 2007, Andi Kleen wrote:
> > I think it would be good if you could specify a default namespace
> > per module, that could reduce the amount of necessary changes significantly.
>
> But also give less documentation. It's also not that difficult to mark
> the exports once. I've
> I think it would be good if you could specify a default namespace
> per module, that could reduce the amount of necessary changes significantly.
But also give less documentation. It's also not that difficult to mark
the exports once. I've forward ported such patches over a few kernels
and didn'
On Thursday 22 November 2007, Andi Kleen wrote:
> #define EXPORT_SYMBOL(sym) \
> - __EXPORT_SYMBOL(sym, "")
> + __EXPORT_SYMBOL(sym, "",,, NULL)
>
> #define EXPORT_SYMBOL_GPL(sym) \
> - __EXPORT_SYMBOL(sym, "_
On Wednesday 28 November 2007 17:48:17 Adrian Bunk wrote:
> On Wed, Nov 28, 2007 at 12:06:45AM +0100, Andi Kleen wrote:
> > On Tue, Nov 27, 2007 at 03:00:22PM -0800, Stephen Hemminger wrote:
> >...
> > > of a modular ipv6 is flawed.
> >
> > Modules that cannot be unloaded are still useful. Standa
On Wed, Nov 28, 2007 at 12:06:45AM +0100, Andi Kleen wrote:
> On Tue, Nov 27, 2007 at 03:00:22PM -0800, Stephen Hemminger wrote:
>...
> > of a modular ipv6 is flawed.
>
> Modules that cannot be unloaded are still useful. Standard case: Distributions
> like to offer an option to not use ipv6 becau
On 11/27/07 7:27 PM, "Rusty Russell" <[EMAIL PROTECTED]> wrote:
> On Tuesday 27 November 2007 16:35:42 Tom Tucker wrote:
>> On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
>> Explicitly documenting what comprises the kernel API (external,
>> supported) and what comprises the kernel imple
On Tuesday 27 November 2007 16:35:42 Tom Tucker wrote:
> On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> Explicitly documenting what comprises the kernel API (external,
> supported) and what comprises the kernel implementation (internal, not
> supported).
But the former is currently an e
On Tuesday 27 November 2007 21:50:16 Andi Kleen wrote:
> Goals are:
> - Limit the interfaces available for out of tree modules to reasonably
> stable ones that are already used by a larger set of drivers.
Not the goals. I haven't seen the *problem* yet.
> - Limit size of exported API to make sta
Adrian Bunk wrote:
On Tue, Nov 27, 2007 at 01:15:23PM -0800, Rick Jones wrote:
The real problem is that these drivers are not in the upstream kernel.
Are there common reasons why these drivers are not upstream?
One might be that upstream has not accepted them. Anything doing or
smelling of
On Tue, Nov 27, 2007 at 03:00:22PM -0800, Stephen Hemminger wrote:
> On Tue, 27 Nov 2007 23:37:43 +0100
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > With my "Enterprise" hat on, I can see where Andi was coming from
> > > originally.
> >
> > For the record my original motivation was to fix the
On Tue, 27 Nov 2007 23:37:43 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> > With my "Enterprise" hat on, I can see where Andi was coming from
> > originally.
>
> For the record my original motivation was to fix the "TCP exports everything
> for ipv6.ko" case cleanly. I later realized that it wo
On Tue, 27 Nov 2007 22:09:42 +0100, Adrian Bunk said:
> Are there common reasons why these drivers are not upstream?
Well, on my laptop, I'm currently dragging along 3 out-of-tree kernel modules.
2 are well-known binary blobs so it's between me and the vendor, as usual.
The third is a USB webcam
> With my "Enterprise" hat on, I can see where Andi was coming from
> originally.
For the record my original motivation was to fix the "TCP exports everything
for ipv6.ko" case cleanly. I later realized that it would be useful for the
ABI stability issues too, but it was really not my primary mot
On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> On Monday 26 November 2007 17:15:44 Roland Dreier wrote:
> > It seems pretty
> > clear to me that having a mechanism that requires modules to make
> > explicit which (semi-)internal APIs makes reviewing easier
>
> Perhaps you've got lot
On Tue, Nov 27, 2007 at 01:15:23PM -0800, Rick Jones wrote:
>> The real problem is that these drivers are not in the upstream kernel.
>>
>> Are there common reasons why these drivers are not upstream?
>
> One might be that upstream has not accepted them. Anything doing or
> smelling of TOE comes
On Tue, Nov 27, 2007 at 10:09:42PM +0100, Adrian Bunk wrote:
> On Tue, Nov 27, 2007 at 02:00:37PM -0500, Dave Jones wrote:
> > On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote:
> >
> > > 1) Why is everyone so concerned that export symbol space is large?
> > > - doe
The real problem is that these drivers are not in the upstream kernel.
Are there common reasons why these drivers are not upstream?
One might be that upstream has not accepted them. Anything doing or
smelling of TOE comes to mind right away.
rick jones
-
To unsubscribe from this list: send
On Tue, Nov 27, 2007 at 02:00:37PM -0500, Dave Jones wrote:
> On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote:
>
> > 1) Why is everyone so concerned that export symbol space is large?
> >- does it cost cpu or running memory?
> >- does it cause bugs?
> >- or are y
On Tue, 27 Nov 2007 15:12:42 +0100, Andi Kleen said:
> > OK, short of making IPv4 a module (which would be a worthy task :)
>
> At some point there were patches, it is probably not very difficult.
> But DaveM resisted at some point because he didn't want people
> to replace the network stack (alth
On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote:
> 1) Why is everyone so concerned that export symbol space is large?
> - does it cost cpu or running memory?
> - does it cause bugs?
> - or are you just worried about "evil modules"?
To clarify something here,
On Tue, Nov 27, 2007 at 11:45:37AM -0600, Tom Tucker wrote:
>
> On Tue, 2007-11-27 at 18:15 +0100, Adrian Bunk wrote:
> > On Mon, Nov 26, 2007 at 11:35:42PM -0600, Tom Tucker wrote:
> > > On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> > >...
> > > > No. That's the wrong question. What
On Tue, 2007-11-27 at 18:15 +0100, Adrian Bunk wrote:
> On Mon, Nov 26, 2007 at 11:35:42PM -0600, Tom Tucker wrote:
> > On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> >...
> > > No. That's the wrong question. What's the real upside?
> >
> > Explicitly documenting what comprises the k
On Tue, Nov 27, 2007 at 10:02:22AM +0100, Andi Kleen wrote:
>...
> That is EXPORT_SYMBOL already. The trouble is just that it covers
> too much. My patchkit is trying to limit it again for a specific
> use case -- exporting an "internal" interface to another module.
> Or rather a set of modules.
>
On Mon, Nov 26, 2007 at 11:35:42PM -0600, Tom Tucker wrote:
> On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
>...
> > No. That's the wrong question. What's the real upside?
>
> Explicitly documenting what comprises the kernel API (external,
> supported) and what comprises the kernel imp
On Tue, Nov 27, 2007 at 08:43:24AM -0700, Jonathan Corbet wrote:
> Might the recent discussion on the exporting of sys_open() and
> sys_read() be an example here? There would appear to be a consensus
> that people should not have used those functions, but they are now
> proving difficult to unexpo
On Tue, Nov 27, 2007 at 08:43:24AM -0700, Jonathan Corbet wrote:
> Rusty said:
>
> > Well, introduce an EXPORT_SYMBOL_INTERNAL(). It's a lot less code. But
> > you'd
> > still need to show that people are having trouble knowing what APIs to use.
>
> Might the recent discussion on the exportin
Rusty said:
> Well, introduce an EXPORT_SYMBOL_INTERNAL(). It's a lot less code. But
> you'd
> still need to show that people are having trouble knowing what APIs to use.
Might the recent discussion on the exporting of sys_open() and
sys_read() be an example here? There would appear to be a
On Tue, Nov 27, 2007 at 03:12:42PM +0100, Andi Kleen wrote:
>
> For Networking: e.g. symbols i put into inet, which are only
> used by protocols (sctp, dccp, udplite, ipv6)
Wait, that's exactly Rusty's point (I think :)
These symbols are exported because they're needed by protocols.
If they weren
> OK, short of making IPv4 a module (which would be a worthy task :)
At some point there were patches, it is probably not very difficult.
But DaveM resisted at some point because he didn't want people
to replace the network stack (although I personally don't have a problem
with that)
> do you hav
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 27, 2007 at 03:26:52PM +1100, Rusty Russell wrote:
>> On Monday 26 November 2007 16:58:08 Roland Dreier wrote:
>> > > > I agree that we shouldn't make things too hard for out-of-tree
>> > > > modules, but I disagree with your first statement: th
On Tue, Nov 27, 2007 at 03:26:52PM +1100, Rusty Russell wrote:
> On Monday 26 November 2007 16:58:08 Roland Dreier wrote:
> > > > I agree that we shouldn't make things too hard for out-of-tree
> > > > modules, but I disagree with your first statement: there clearly is a
> > > > large class of sy
> > Perhaps you've got lots of patches were people are using internal APIs they
> > shouldn't?
> >
>
> Maybe the issue is "who can tell" since what is external and what is
> internal is not explicitly defined?
Exactly. Or rather it is not defined on the module level. We got
"static" of cours
On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> On Monday 26 November 2007 17:15:44 Roland Dreier wrote:
> > > Except C doesn't have namespaces and this mechanism doesn't create them.
> > > So this is just complete and utter makework; as I said before, noone's
> > > going to confuse
On Monday 26 November 2007 17:15:44 Roland Dreier wrote:
> > Except C doesn't have namespaces and this mechanism doesn't create them.
> > So this is just complete and utter makework; as I said before, noone's
> > going to confuse all those udp_* functions if they're not in the udp
> > namespac
On Monday 26 November 2007 16:58:08 Roland Dreier wrote:
> > > I agree that we shouldn't make things too hard for out-of-tree
> > > modules, but I disagree with your first statement: there clearly is a
> > > large class of symbols that are used by multiple modules but which are
> > > not generi
> Agreed. On first glance, I was intrigued but:
>
> 1) Why is everyone so concerned that export symbol space is large?
> - does it cost cpu or running memory?
> - does it cause bugs?
> - or are you just worried about "evil modules"?
>
> 2) These aren't real namespaces
>
On Mon, 26 Nov 2007 12:28:14 +1100
Rusty Russell <[EMAIL PROTECTED]> wrote:
> On Monday 26 November 2007 07:27:03 Roland Dreier wrote:
> > > This patch allows to export symbols only for specific modules by
> > > introducing symbol name spaces. A module name space has a white
> > > list of modul
> Except C doesn't have namespaces and this mechanism doesn't create them. So
> this is just complete and utter makework; as I said before, noone's going to
> confuse all those udp_* functions if they're not in the udp namespace.
I don't understand why you're so opposed to organizing the ker
> > I agree that we shouldn't make things too hard for out-of-tree
> > modules, but I disagree with your first statement: there clearly is a
> > large class of symbols that are used by multiple modules but which are
> > not generically useful -- they are only useful by a certain small class
>
On Monday 26 November 2007 07:27:03 Roland Dreier wrote:
> > 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.
On Monday 26 November 2007 07:29:39 Roland Dreier wrote:
> > Yes, and if a symbol is already used by multiple modules, it's
> > generically useful. And if so, why restrict it to in-tree modules?
>
> I agree that we shouldn't make things too hard for out-of-tree
> modules, but I disagree with you
On Saturday 24 November 2007 23:39:43 Andi Kleen wrote:
> On Sat, Nov 24, 2007 at 03:53:34PM +1100, Rusty Russell wrote:
> > So, you're saying that there's a problem with in-tree modules using
> > symbols they shouldn't? Can you give an example?
[ Note: no response to this ]
> > If people aren't
> Yes, and if a symbol is already used by multiple modules, it's generically
> useful. And if so, why restrict it to in-tree modules?
I agree that we shouldn't make things too hard for out-of-tree
modules, but I disagree with your first statement: there clearly is a
large class of symbols 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(na
On Sat, Nov 24, 2007 at 03:53:34PM +1100, Rusty Russell wrote:
> 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 ca
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,
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
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
On Nov 23, 2007 2:19 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > Andy, I like your idea. IMHO, as Rusty said a simple EXPORT_SYMBOL_TO
> > is better.
>
> I don't think so. e.g. tcpcong would be very very messy this way.
>
> > And I wonder if it is possible to export to something like the stru
On Friday 23 November 2007 01:25, Rusty Russell wrote:
> On Thursday 22 November 2007 22:05:45 Christoph Hellwig wrote:
> > On Thu, Nov 22, 2007 at 02:56:22PM +1100, Rusty Russell wrote:
> > > This is an interesting idea, thanks for the code! My only question
> > > is whether we can get most o
On Thursday 22 November 2007 22:05:45 Christoph Hellwig wrote:
> On Thu, Nov 22, 2007 at 02:56:22PM +1100, Rusty Russell wrote:
> > This is an interesting idea, thanks for the code! My only question
> > is whether we can get most of this benefit by dropping the indirection of
> > namespaces an
On Thursday 22 November 2007 22:46:23 Andi Kleen wrote:
> On Thursday 22 November 2007 04:56, Rusty Russell wrote:
> > This is an interesting idea, thanks for the code! My only question
> > is whether we can get most of this benefit by dropping the indirection of
> > namespaces and have someth
> Andy, I like your idea. IMHO, as Rusty said a simple EXPORT_SYMBOL_TO
> is better.
I don't think so. e.g. tcpcong would be very very messy this way.
> And I wonder if it is possible to export to something like the struct
> device_driver? If it's possible then it will not limited to modules.
> Creating the DCCP and its congestion control infrastructure (CCID)
> module namespaces is now on my TODO list. :-)
My original patchkit had DCCP actually done, but I ran into some problem
while forward porting and disabled it again. But should be reasonably
easy to resurrect.
-Andi
-
To unsubs
On Thu, Nov 22, 2007 at 12:54:49PM +0100, Andi Kleen wrote:
> On Thursday 22 November 2007 12:06, Christoph Hellwig wrote:
> > Very nice, looking forward to organize the exports mess a bit more.
>
> I would need people to help me converting more subsystems to this new scheme.
>
> In particular al
Em Thu, Nov 22, 2007 at 03:43:06AM +0100, Andi Kleen escreveu:
>
> 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
> i
On Thursday 22 November 2007 12:06, Christoph Hellwig wrote:
> Very nice, looking forward to organize the exports mess a bit more.
I would need people to help me converting more subsystems to this new scheme.
In particular all exports that are only used by a single module are direct
candidates f
On Thursday 22 November 2007 04:56, Rusty Russell wrote:
> This is an interesting idea, thanks for the code! My only question is
> whether we can get most of this benefit by dropping the indirection of
> namespaces and have something like "EXPORT_SYMBOL_TO(sym, modname)"? It
> doesn't work s
Very nice, looking forward to organize the exports mess a bit more.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/
On Thu, Nov 22, 2007 at 02:56:22PM +1100, Rusty Russell wrote:
> This is an interesting idea, thanks for the code! My only question is
> whether we can get most of this benefit by dropping the indirection of
> namespaces and have something like "EXPORT_SYMBOL_TO(sym, modname)"? It
> doesn't
On Nov 22, 2007 11:56 AM, Rusty Russell <[EMAIL PROTECTED]> wrote:
> On Thursday 22 November 2007 13:43:06 Andi Kleen 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 import
On Thursday 22 November 2007 13:43:06 Andi Kleen 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 o
On Thu, Nov 22, 2007 at 03:43:06AM +0100, Andi Kleen 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
> 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,
On Thu, 22 Nov 2007 03:43:06 +0100 (CET)
Andi Kleen <[EMAIL PROTECTED]> 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
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 purp
68 matches
Mail list logo
