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
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 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
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 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, _gpl)
+
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't
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
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 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 symbol
But
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.
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
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 because
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. Standard case:
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
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
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
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
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
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
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
> 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
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
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?
> > > -
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
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
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.
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
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
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
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
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
> 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
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:
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
> > 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
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 course, but I
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 symbols that
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: there clearly is
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 have
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't
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 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 exporting of
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 unexport.
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
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 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 kernel API
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's the real
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, by
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 (although
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 you just
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 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?
- does it cost
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 to mind
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 lots of
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
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
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 would be
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 TCP exports
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
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
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 stable
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 implementation
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
> >
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
> 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
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 modules that are
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
- all
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 generically
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
namespace.
I
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 all those
> 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
> > 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
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
> 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
> 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:
>
>
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:
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
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
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 your
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.
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
of
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
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
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 cannot
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 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 modules?
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
1 - 100 of 136 matches
Mail list logo
