Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 this patch makes that worse, not better. > > - does it cause bugs? > > yes, bad apis are causing bugs... sys_open is just the starter of that. Sure, but this doesn't change the APIs, either. We seem to have fixed sys_open the right way, and since we're not supposed to care about out-of-tree modules... Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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... sys_open is just the starter of that. -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 forward ported such patches over a few kernels > and didn't run into significant me Part of your sentence seems to be missing, but I guess I understand your point. How many files did you annotate this way? I can see it as being useful to have the namespace explicit in each symbol, but doing it once per module sounds like the 80% solution for 20% of the work, and the two don't even conflict. In the current kernel, I count 12644 exported symbols in 1646 files, in 540 directories. One problem I can see with annotating every symbol is that it conflicts with other patches that add more exported functions to a file without adding the namespace, or that simply break because of context changes. Arnd <>< - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
> 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 run into significant me > obj-$(CONFIG_COMBINED) += combined.o > combined-$(CONFIG_SUBOPTION) += combined_main.o combined_other.o > obj-$(CONFIG_SINGLE) += single.o > obj-$(CONFIG_OTHER) += other.o > obj-$(CONFIG_API) += api.o > > NAMESPACE = subsys # default, used for other.o > NAMESPACE_single.o = single # used only for single.o > NAMESPACE_combined.o = combined # all parts of combined.o > NAMESPACE_combined_other.o = special #except this one > NAMESPACE_api.o =# api.o is put into the global ns I would prefer to keep that inside the source files, again for documentation purposes. One goal of namespace was to make something that was previously kind of implicit explicit and the default name spaces would work against that again I think. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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") > + __EXPORT_SYMBOL(sym, "_gpl",,, NULL) > > #define EXPORT_SYMBOL_GPL_FUTURE(sym) \ > - __EXPORT_SYMBOL(sym, "_gpl_future") > + __EXPORT_SYMBOL(sym, "_gpl_future",,, NULL) > > +/* Export symbol into namespace ns > + * No _GPL variants because namespaces imply GPL only > + */ > +#define EXPORT_SYMBOL_NS(ns, sym) \ > + __EXPORT_SYMBOL(sym, "_gpl",__##ns, NS_SEPARATOR #ns, #ns) > I think it would be good if you could specify a default namespace per module, that could reduce the amount of necessary changes significantly. For example, you can do #define EXPORT_SYMBOL_GLOBAL(sym) __EXPORT_SYMBOL(sym, "_gpl",,, NULL) #ifdef MODULE_NAMESPACE #define EXPORT_SYMBOL_GPL(sym) EXPORT_SYMBOL_GLOBAL(sym) #else #define EXPORT_SYMBOL_GPL(sym) EXPORT_SYMBOL_NS(sym, MODULE_NAMESPACE) #endif If we go that way, it may be useful to extend the namespace mechanism to non-GPL symbols as well, like #define EXPORT_SYMBOL(sym) __EXPORT_SYMBOL(sym, "",__## MODULE_NAMESPACE, NS_SEPARATOR #MODULE_NAMESPACE, #MODULE_NAMESPACE) Unfortunately, doing this automatic namespace selection requires to set the namespace before #include . One way to work around this could be to use Makefile magic so you can list a Makefile as obj-$(CONFIG_COMBINED) += combined.o combined-$(CONFIG_SUBOPTION) += combined_main.o combined_other.o obj-$(CONFIG_SINGLE) += single.o obj-$(CONFIG_OTHER) += other.o obj-$(CONFIG_API) += api.o NAMESPACE = subsys # default, used for other.o NAMESPACE_single.o = single # used only for single.o NAMESPACE_combined.o = combined # all parts of combined.o NAMESPACE_combined_other.o = special #except this one NAMESPACE_api.o =# api.o is put into the global ns The Makefile logic here would basically just follow the rules we have for CFLAGS etc, and then pass -DMODULE_NAMESPACE=$(NAMESPACE_$(obj)) to gcc. Arnd <>< - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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) + __EXPORT_SYMBOL(sym, _gpl,,, NULL) #define EXPORT_SYMBOL_GPL_FUTURE(sym) \ - __EXPORT_SYMBOL(sym, _gpl_future) + __EXPORT_SYMBOL(sym, _gpl_future,,, NULL) +/* Export symbol into namespace ns + * No _GPL variants because namespaces imply GPL only + */ +#define EXPORT_SYMBOL_NS(ns, sym) \ + __EXPORT_SYMBOL(sym, _gpl,__##ns, NS_SEPARATOR #ns, #ns) I think it would be good if you could specify a default namespace per module, that could reduce the amount of necessary changes significantly. For example, you can do #define EXPORT_SYMBOL_GLOBAL(sym) __EXPORT_SYMBOL(sym, _gpl,,, NULL) #ifdef MODULE_NAMESPACE #define EXPORT_SYMBOL_GPL(sym) EXPORT_SYMBOL_GLOBAL(sym) #else #define EXPORT_SYMBOL_GPL(sym) EXPORT_SYMBOL_NS(sym, MODULE_NAMESPACE) #endif If we go that way, it may be useful to extend the namespace mechanism to non-GPL symbols as well, like #define EXPORT_SYMBOL(sym) __EXPORT_SYMBOL(sym, ,__## MODULE_NAMESPACE, NS_SEPARATOR #MODULE_NAMESPACE, #MODULE_NAMESPACE) Unfortunately, doing this automatic namespace selection requires to set the namespace before #include linux/module.h. One way to work around this could be to use Makefile magic so you can list a Makefile as obj-$(CONFIG_COMBINED) += combined.o combined-$(CONFIG_SUBOPTION) += combined_main.o combined_other.o obj-$(CONFIG_SINGLE) += single.o obj-$(CONFIG_OTHER) += other.o obj-$(CONFIG_API) += api.o NAMESPACE = subsys # default, used for other.o NAMESPACE_single.o = single # used only for single.o NAMESPACE_combined.o = combined # all parts of combined.o NAMESPACE_combined_other.o = special #except this one NAMESPACE_api.o =# api.o is put into the global ns The Makefile logic here would basically just follow the rules we have for CFLAGS etc, and then pass -DMODULE_NAMESPACE=$(NAMESPACE_$(obj)) to gcc. Arnd - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 run into significant me obj-$(CONFIG_COMBINED) += combined.o combined-$(CONFIG_SUBOPTION) += combined_main.o combined_other.o obj-$(CONFIG_SINGLE) += single.o obj-$(CONFIG_OTHER) += other.o obj-$(CONFIG_API) += api.o NAMESPACE = subsys # default, used for other.o NAMESPACE_single.o = single # used only for single.o NAMESPACE_combined.o = combined # all parts of combined.o NAMESPACE_combined_other.o = special #except this one NAMESPACE_api.o =# api.o is put into the global ns I would prefer to keep that inside the source files, again for documentation purposes. One goal of namespace was to make something that was previously kind of implicit explicit and the default name spaces would work against that again I think. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 forward ported such patches over a few kernels and didn't run into significant me Part of your sentence seems to be missing, but I guess I understand your point. How many files did you annotate this way? I can see it as being useful to have the namespace explicit in each symbol, but doing it once per module sounds like the 80% solution for 20% of the work, and the two don't even conflict. In the current kernel, I count 12644 exported symbols in 1646 files, in 540 directories. One problem I can see with annotating every symbol is that it conflicts with other patches that add more exported functions to a file without adding the namespace, or that simply break because of context changes. Arnd - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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... sys_open is just the starter of that. -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 this patch makes that worse, not better. - does it cause bugs? yes, bad apis are causing bugs... sys_open is just the starter of that. Sure, but this doesn't change the APIs, either. We seem to have fixed sys_open the right way, and since we're not supposed to care about out-of-tree modules... Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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: > > Distributions > > like to offer an option to not use ipv6 because that is popular workaround > > for the common "DNS server eats queries and causes delays" issue. > > Forcing the user to rebuild the kernel for this wouldn't be practical. > > If ipv6 wasn't modular that would be hard to do. > > It should be trivial doing it similar to the selinux=0 boot option. They safe also a few hundred KB of memory this way. I know it is not en vogue anymore to care about memory bloat, but I personally like that. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 that is popular workaround > for the common "DNS server eats queries and causes delays" issue. > Forcing the user to rebuild the kernel for this wouldn't be practical. > If ipv6 wasn't modular that would be hard to do. It should be trivial doing it similar to the selinux=0 boot option. > -Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 that is popular workaround for the common DNS server eats queries and causes delays issue. Forcing the user to rebuild the kernel for this wouldn't be practical. If ipv6 wasn't modular that would be hard to do. It should be trivial doing it similar to the selinux=0 boot option. -Andi cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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: Distributions like to offer an option to not use ipv6 because that is popular workaround for the common DNS server eats queries and causes delays issue. Forcing the user to rebuild the kernel for this wouldn't be practical. If ipv6 wasn't modular that would be hard to do. It should be trivial doing it similar to the selinux=0 boot option. They safe also a few hundred KB of memory this way. I know it is not en vogue anymore to care about memory bloat, but I personally like that. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 (internal, not >> supported). > > But the former is currently an empty set. > Yes, I overstated this. >> - making it obvious to developers when they are binding their >> implementation to a particular kernel release > > See, there's your problem. All interfaces can, and will, change. You're > always binding yourself to a particular release. > Absolutely in the limit. But there are many bits of code that work quite nicely from release to release because they use services that live in the smooth water in the wake of the Linux head. I think defining that smooth water has merit. I also think that it would be nice to limit the scope of module externs to avoid polluting the global namespace. I'm not sure that this particular patch reaches these goals, but it prompted me to comment. > So you're not proposing we mark what's not stable, you're arguing that we > create a subset which is stable. > Well, this is an interesting question. The answer is I think both are important. It would be nice (and arguably necessary long term) to limit the scope of externs. This can be accomplished with name spaces "I want bob's implementation of read." I think it also has value to define interfaces that are considered stable (but not inviolate) to allow developers to make better informed decisions when choosing interfaces. Having this info explicit in the code seems logical to me. > That's an argument we're not (yet) having. > Yeah, maybe I'm off in the weeds on this one... Tom > Cheers, > Rusty. > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 empty set. > - making it obvious to developers when they are binding their > implementation to a particular kernel release See, there's your problem. All interfaces can, and will, change. You're always binding yourself to a particular release. So you're not proposing we mark what's not stable, you're arguing that we create a subset which is stable. That's an argument we're not (yet) having. Cheers, Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 ABIs for enterprise > distributions easier > [Yes I know that is not a popular topic on l-k, but it's a day-to-day > problem for these distros and out of tree solutions do not work] That's a real problem, and I sympathise with the idea of marking symbols as externally useful (or, practically, mark internal). But we now need to decide what's "externally useful". The currently line for exports is simple: someone in-tree needs it. You dislike the suggestion to extend this to "if more than one in-tree needs it it's open". Currently your criterion seems to be "does the maintainer hate external modules?" which I don't think will be what you want... Cheers, Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 TOE comes to mind right away. Which modules doing or smelling of TOE do work with unmodified vendor kernels? At the very real risk of further demonstrating my Linux vocabulary limitations, I believe there is a "Linux Sockets Acceleration" module/whatnot for NetXen and related 10G NICs, and a cxgb3_toe (?) module for Chelsio 10G NICs. rick jones - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 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 motivation. > > This is why I didn't even mention that in the original patch description. > > Since ipv6 can never be removed because it references itself, the whole > concept AFAIK that is obsolete anyways. It was done because it was feared it would be broken, but at least the broken cases I knew about were all fixed a long time ago. Most likely it could be safely removed. > 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 that is popular workaround for the common "DNS server eats queries and causes delays" issue. Forcing the user to rebuild the kernel for this wouldn't be practical. If ipv6 wasn't modular that would be hard to do. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 useful for the > ABI stability issues too, but it was really not my primary motivation. > This is why I didn't even mention that in the original patch description. Since ipv6 can never be removed because it references itself, the whole concept of a modular ipv6 is flawed. Sometime ago a patch was sent to remove the ipv6 module unload hooks but as I recall Dave rejected it believing the unload code could be fixed. -- Stephen Hemminger <[EMAIL PROTECTED]> - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 driver that happened to get caught at the wrong end of the colorspace-conversion-in-kernel bunfight in the V4L playpen. Somebody wants to figure out how to get the gspca drivers into the kernel, they're at http://mxhaard.free.fr/download.html waiting for attention. ;) (Don't look at *me*, I don't understand the code, or the bunfight - I just happen to have one of the 244 supported webcams, and it works with that driver) pgp71FKUdkLqz.pgp Description: PGP signature
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
> 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 motivation. This is why I didn't even mention that in the original patch description. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 patches were people are using internal APIs they > shouldn't? With my "Enterprise" hat on, I can see where Andi was coming from originally. Just like we do in RHEL, SuSE have a concept of a kernel ABI and we too have a concept of a whitelist of symbols - a subset of kernel ABI that is approved for use by third parties (this is nothing to do with licensing, this is to do with ABI stability we try to ensure). As part of figuring out what should and should not be used by external modules (outside of the core kernel), we've gained a bit of experience, and it would be nice to be able to help others - this is nothing to do with upstream "ABI stability", but just to be of a public service by documenting those functions that are never intended for modules but which necessarily are exported because they have one or two users. > > , makes it > > easier to communicate "please don't use that API" to module authors, > > 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. I suggested this exact idea privately at OLS. I still think it's the best compromise, though I like bits of the namespace idea. An EXPORT_SYMBOL_INTERNAL would indeed be trivial. Jon. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 right away. Which modules doing or smelling of TOE do work with unmodified vendor kernels? AFAIR TOE was both not a module and required some hooks in the network stack, so it's completely outside the scope of this thread. > rick jones cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 cpu or running memory? > > > - does it cause bugs? > > > - or are you just worried about "evil modules"? > > > > To clarify something here, by "evil", don't necessarily think "binary > > only". > > > > Out of tree modules are frequently using symbols that they shouldn't be. > > Because they get no peer-review here, they 'get away with it' for the most > > part. > > Until distro vendors push rebased kernel updates that removed exports that > > should never have been exported, and suddenly people like me get bombed > > with "Fedora broke my xyz driver" mails. > >... > > The real problem is that these drivers are not in the upstream kernel. You're preaching to the choir. > Are there common reasons why these drivers are not upstream? It varies case by case. Dave -- http://www.codemonkey.org.uk - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 worried about "evil modules"? > > To clarify something here, by "evil", don't necessarily think "binary only". > > Out of tree modules are frequently using symbols that they shouldn't be. > Because they get no peer-review here, they 'get away with it' for the most > part. > Until distro vendors push rebased kernel updates that removed exports that > should never have been exported, and suddenly people like me get bombed > with "Fedora broke my xyz driver" mails. >... The real problem is that these drivers are not in the upstream kernel. Are there common reasons why these drivers are not upstream? > Dave cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 I personally don't have a problem > with that) Personally, I wouldn't find replacing the ipv4 stack very interesting. However, stress-testing your system for IPv6-readiness by doing 'rmmod ipv4' :) (Though I admit it's something I'd *try* if it was available, but certainly not sufficient for a reason to do it...) pgpVTFRKcAUhD.pgp Description: PGP signature
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 "evil", don't necessarily think "binary only". Out of tree modules are frequently using symbols that they shouldn't be. Because they get no peer-review here, they 'get away with it' for the most part. Until distro vendors push rebased kernel updates that removed exports that should never have been exported, and suddenly people like me get bombed with "Fedora broke my xyz driver" mails. Reducing the opportunity for people to screw things up is a good thing. If a symbol is exported, most out-of-tree driver authors seem to think its "fair game" to use it. Dave -- http://www.codemonkey.org.uk - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 upside? > > > > > > Explicitly documenting what comprises the kernel API (external, > > > supported) and what comprises the kernel implementation (internal, not > > > supported). > > >... > > > > There is not, never was, and never will be, any supported external API > > of the kernel. > > Philosophically I understand what you're saying, but in practical terms > there is the issue of managing core API like kmalloc. Although kmalloc > _could_ change, doing so would be extremely painful. In fact anyone who > proposed such a change would have to have a profoundly powerful argument > as to why it was necessary. The latter should at least in theory be required for all changes no matter how core they are... > I think this patchset is an attempt to make it easier to identify and > review these kinds of interfaces. As long as the submitter fixes all in-kernel users these interfaces are not handled differently from interfaces with fewer users. And I remember at least one commit that changed > 1000 files because it changed a frequently used driver API. [1] cu Adrian [1] commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 (external, > > supported) and what comprises the kernel implementation (internal, not > > supported). > >... > > There is not, never was, and never will be, any supported external API > of the kernel. Philosophically I understand what you're saying, but in practical terms there is the issue of managing core API like kmalloc. Although kmalloc _could_ change, doing so would be extremely painful. In fact anyone who proposed such a change would have to have a profoundly powerful argument as to why it was necessary. I think this patchset is an attempt to make it easier to identify and review these kinds of interfaces. > > cu > Adrian > - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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. > > Standard example is TCP: TCP exports nearly everything and the > single user is the TCP code in ipv6.ko. Instead those symbols should > be limited to be only accessable to ipv6.ko. >... Let's forget about external modules that are anyway irrelevant for upstream kernel development. Do you have past examples where this would have brought advantages for the upstream kernel justifying all the work required for creating and maintaining these namespaces? IOW, where modules were submitted for upstream inclusion and merging them was impossible or much harder only because they were developed aginst the wrong API? > -ANdi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 implementation (internal, not > supported). >... There is not, never was, and never will be, any supported external API of the kernel. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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. They're not. The exports aren't used anymore and could just go away any time. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 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. That is a good example yes. > Perhaps the best use of the namespace stuff might be for *future* > exports which are needed to help make the mainline kernel fully modular, > but which are not meant to be part of a more widely-used API? Not sure about future only, but yes that is its intention. Thanks for putting it clearly. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 consensus that people should not have used those functions, but they are now proving difficult to unexport. Perhaps the best use of the namespace stuff might be for *future* exports which are needed to help make the mainline kernel fully modular, but which are not meant to be part of a more widely-used API? jon - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 available to everyone then it would be difficult
to start writing new protocols.
> I already caught someone doing something wrong with that BTW --
> wanrouter clearly does some things it shouldn't be doing.
Can you be more precise?
> Or the fib namespace, where all the fib functions should be only
> used by the two fib_* modules and ipv6/decnet.
Again, if it's used by decnet then it sounds like it should be
exported because new protocol families may need them.
So based on the network code at least I'm kind of starting to
agree with Rusty now: if a symbol is needed by more than one
in-tree module chances are we want it to be exported for all.
Although I admit I haven't examined your examples elsewhere.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
> 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 an example where a symbol is used by more than one module > but needs to be put into a namespace? For SCSI: SD,SR,SG etc. For Networking: e.g. symbols i put into inet, which are only used by protocols (sctp, dccp, udplite, ipv6) I already caught someone doing something wrong with that BTW -- wanrouter clearly does some things it shouldn't be doing. Or the fib namespace, where all the fib functions should be only used by the two fib_* modules and ipv6/decnet. For KVM: the exports used by kvm_amd/intel For arch/x86: e.g. e820_*, IO_APIC_get_PCI_irq_vector, swiotlb, a lot of stuff only used by acpi processor.c, pcibios*, etc.etc. Roland gave another example for Infiniband. Also in general it allows flexibility later if modules get split. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 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 modules.
>> > >
>> > > If it is so clear, you should be able to easily provide examples?
>> >
>> > Sure -- Andi's example of symbols required only by TCP congestion
>> > modules;
>>
>> Exactly. Why exactly should someone not write a new TCP congestion module?
>
> Agreed the congestion modules are a corner case. I even mentioned that in the
> patch. I would be happy to drop that one if that is the consensus.
> It was more done as a example anyways. That is why I made it an separate
> namespace from "tcp"
>
> But for many other TCP symbols it makes a lot of sense: all the functions
> only used by tcp_ipv6.c. If someone wants to write support for a "IPv7" or
> similar they really should do it in tree. So I think the "tcp" and "inet"
> namespaces make a lot of sense.
OK, short of making IPv4 a module (which would be a worthy task :)
do you have an example where a symbol is used by more than one module
but needs to be put into a namespace?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 are used by multiple modules but which are > > > > not generically useful -- they are only useful by a certain small > > > > class of modules. > > > > > > If it is so clear, you should be able to easily provide examples? > > > > Sure -- Andi's example of symbols required only by TCP congestion > > modules; > > Exactly. Why exactly should someone not write a new TCP congestion module? Agreed the congestion modules are a corner case. I even mentioned that in the patch. I would be happy to drop that one if that is the consensus. It was more done as a example anyways. That is why I made it an separate namespace from "tcp" But for many other TCP symbols it makes a lot of sense: all the functions only used by tcp_ipv6.c. If someone wants to write support for a "IPv7" or similar they really should do it in tree. So I think the "tcp" and "inet" namespaces make a lot of sense. > Right. So presumably there will only ever be two drivers using this core > code, so no new users will ever be written? Now we've found one use case, is If there are new users they will need to get proper review and should be in tree. MODULE_ALLOW() enforces that. > it worth the complexity of namespaces? Is it worth the halfway point of What complexity? You're always claiming it is complex. It isn't really. > export-to-module? > > No, we've seen the solution and various people applying it. I'm still trying > to discover the problem it's solving. Again for rusty @) 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. This can also have further downstream advantages. For example it might be a reasonable future rule to require all unconditionally EXPORT_SYMBOL()s to have a complete LinuxDoc documentation entry. - Explicitely declare in source what is clearly internal and not intended to be a generally usable interface. e.g. for the LinuxDoc example above such internal functions don't necessarily need full LinuxDoc documentation. - Force review from core maintainers for use of such internal interfaces - Limit size of exported API to make stable ABIs for enterprise distributions easier [Yes I know that is not a popular topic on l-k, but it's a day-to-day problem for these distros and out of tree solutions do not work] -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
> > 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 think we should have a similar mechanism on a module level. > Explicitly documenting what comprises the kernel API (external, > supported) It would not be fully supported either -- can still change etc. -- but there is a reasonable expectation that those external APIs will change less often than internal interfaces. > - forcing developers to identify their exports as part of the > implementation or as part of the kernel API 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. Standard example is TCP: TCP exports nearly everything and the single user is the TCP code in ipv6.ko. Instead those symbols should be limited to be only accessable to ipv6.ko. The reason I went with the more generic namespace mechanism instead of EXPORT_SYMBOL_TO() is that ipv6 is ever split up it would still work. Also using namespaces doesn't have any more overhead than EXPORT_SYMBOL_TO() and the complexity is about the same (not very much anyways -- just look at the patches) > - making it easier for reviewers to identify when developers are adding > to the kernel API and thereby focusing the appropriate level of review > to the new function That is another reason. -ANdi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 think we should have a similar mechanism on a module level. Explicitly documenting what comprises the kernel API (external, supported) It would not be fully supported either -- can still change etc. -- but there is a reasonable expectation that those external APIs will change less often than internal interfaces. - forcing developers to identify their exports as part of the implementation or as part of the kernel API 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. Standard example is TCP: TCP exports nearly everything and the single user is the TCP code in ipv6.ko. Instead those symbols should be limited to be only accessable to ipv6.ko. The reason I went with the more generic namespace mechanism instead of EXPORT_SYMBOL_TO() is that ipv6 is ever split up it would still work. Also using namespaces doesn't have any more overhead than EXPORT_SYMBOL_TO() and the complexity is about the same (not very much anyways -- just look at the patches) - making it easier for reviewers to identify when developers are adding to the kernel API and thereby focusing the appropriate level of review to the new function That is another reason. -ANdi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 are used by multiple modules but which are not generically useful -- they are only useful by a certain small class of modules. If it is so clear, you should be able to easily provide examples? Sure -- Andi's example of symbols required only by TCP congestion modules; Exactly. Why exactly should someone not write a new TCP congestion module? Agreed the congestion modules are a corner case. I even mentioned that in the patch. I would be happy to drop that one if that is the consensus. It was more done as a example anyways. That is why I made it an separate namespace from tcp But for many other TCP symbols it makes a lot of sense: all the functions only used by tcp_ipv6.c. If someone wants to write support for a IPv7 or similar they really should do it in tree. So I think the tcp and inet namespaces make a lot of sense. Right. So presumably there will only ever be two drivers using this core code, so no new users will ever be written? Now we've found one use case, is If there are new users they will need to get proper review and should be in tree. MODULE_ALLOW() enforces that. it worth the complexity of namespaces? Is it worth the halfway point of What complexity? You're always claiming it is complex. It isn't really. export-to-module? No, we've seen the solution and various people applying it. I'm still trying to discover the problem it's solving. Again for rusty @) 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. This can also have further downstream advantages. For example it might be a reasonable future rule to require all unconditionally EXPORT_SYMBOL()s to have a complete LinuxDoc documentation entry. - Explicitely declare in source what is clearly internal and not intended to be a generally usable interface. e.g. for the LinuxDoc example above such internal functions don't necessarily need full LinuxDoc documentation. - Force review from core maintainers for use of such internal interfaces - Limit size of exported API to make stable ABIs for enterprise distributions easier [Yes I know that is not a popular topic on l-k, but it's a day-to-day problem for these distros and out of tree solutions do not work] -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 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 modules.
If it is so clear, you should be able to easily provide examples?
Sure -- Andi's example of symbols required only by TCP congestion
modules;
Exactly. Why exactly should someone not write a new TCP congestion module?
Agreed the congestion modules are a corner case. I even mentioned that in the
patch. I would be happy to drop that one if that is the consensus.
It was more done as a example anyways. That is why I made it an separate
namespace from tcp
But for many other TCP symbols it makes a lot of sense: all the functions
only used by tcp_ipv6.c. If someone wants to write support for a IPv7 or
similar they really should do it in tree. So I think the tcp and inet
namespaces make a lot of sense.
OK, short of making IPv4 a module (which would be a worthy task :)
do you have an example where a symbol is used by more than one module
but needs to be put into a namespace?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 an example where a symbol is used by more than one module but needs to be put into a namespace? For SCSI: SD,SR,SG etc. For Networking: e.g. symbols i put into inet, which are only used by protocols (sctp, dccp, udplite, ipv6) I already caught someone doing something wrong with that BTW -- wanrouter clearly does some things it shouldn't be doing. Or the fib namespace, where all the fib functions should be only used by the two fib_* modules and ipv6/decnet. For KVM: the exports used by kvm_amd/intel For arch/x86: e.g. e820_*, IO_APIC_get_PCI_irq_vector, swiotlb, a lot of stuff only used by acpi processor.c, pcibios*, etc.etc. Roland gave another example for Infiniband. Also in general it allows flexibility later if modules get split. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 available to everyone then it would be difficult
to start writing new protocols.
I already caught someone doing something wrong with that BTW --
wanrouter clearly does some things it shouldn't be doing.
Can you be more precise?
Or the fib namespace, where all the fib functions should be only
used by the two fib_* modules and ipv6/decnet.
Again, if it's used by decnet then it sounds like it should be
exported because new protocol families may need them.
So based on the network code at least I'm kind of starting to
agree with Rusty now: if a symbol is needed by more than one
in-tree module chances are we want it to be exported for all.
Although I admit I haven't examined your examples elsewhere.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 consensus that people should not have used those functions, but they are now proving difficult to unexport. Perhaps the best use of the namespace stuff might be for *future* exports which are needed to help make the mainline kernel fully modular, but which are not meant to be part of a more widely-used API? jon - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 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. That is a good example yes. Perhaps the best use of the namespace stuff might be for *future* exports which are needed to help make the mainline kernel fully modular, but which are not meant to be part of a more widely-used API? Not sure about future only, but yes that is its intention. Thanks for putting it clearly. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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. They're not. The exports aren't used anymore and could just go away any time. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 implementation (internal, not supported). ... There is not, never was, and never will be, any supported external API of the kernel. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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. Standard example is TCP: TCP exports nearly everything and the single user is the TCP code in ipv6.ko. Instead those symbols should be limited to be only accessable to ipv6.ko. ... Let's forget about external modules that are anyway irrelevant for upstream kernel development. Do you have past examples where this would have brought advantages for the upstream kernel justifying all the work required for creating and maintaining these namespaces? IOW, where modules were submitted for upstream inclusion and merging them was impossible or much harder only because they were developed aginst the wrong API? -ANdi cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 (external, supported) and what comprises the kernel implementation (internal, not supported). ... There is not, never was, and never will be, any supported external API of the kernel. Philosophically I understand what you're saying, but in practical terms there is the issue of managing core API like kmalloc. Although kmalloc _could_ change, doing so would be extremely painful. In fact anyone who proposed such a change would have to have a profoundly powerful argument as to why it was necessary. I think this patchset is an attempt to make it easier to identify and review these kinds of interfaces. cu Adrian - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 upside? Explicitly documenting what comprises the kernel API (external, supported) and what comprises the kernel implementation (internal, not supported). ... There is not, never was, and never will be, any supported external API of the kernel. Philosophically I understand what you're saying, but in practical terms there is the issue of managing core API like kmalloc. Although kmalloc _could_ change, doing so would be extremely painful. In fact anyone who proposed such a change would have to have a profoundly powerful argument as to why it was necessary. The latter should at least in theory be required for all changes no matter how core they are... I think this patchset is an attempt to make it easier to identify and review these kinds of interfaces. As long as the submitter fixes all in-kernel users these interfaces are not handled differently from interfaces with fewer users. And I remember at least one commit that changed 1000 files because it changed a frequently used driver API. [1] cu Adrian [1] commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5 -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 evil, don't necessarily think binary only. Out of tree modules are frequently using symbols that they shouldn't be. Because they get no peer-review here, they 'get away with it' for the most part. Until distro vendors push rebased kernel updates that removed exports that should never have been exported, and suddenly people like me get bombed with Fedora broke my xyz driver mails. Reducing the opportunity for people to screw things up is a good thing. If a symbol is exported, most out-of-tree driver authors seem to think its fair game to use it. Dave -- http://www.codemonkey.org.uk - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 I personally don't have a problem with that) Personally, I wouldn't find replacing the ipv4 stack very interesting. However, stress-testing your system for IPv6-readiness by doing 'rmmod ipv4' :) (Though I admit it's something I'd *try* if it was available, but certainly not sufficient for a reason to do it...) pgpVTFRKcAUhD.pgp Description: PGP signature
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 worried about evil modules? To clarify something here, by evil, don't necessarily think binary only. Out of tree modules are frequently using symbols that they shouldn't be. Because they get no peer-review here, they 'get away with it' for the most part. Until distro vendors push rebased kernel updates that removed exports that should never have been exported, and suddenly people like me get bombed with Fedora broke my xyz driver mails. ... The real problem is that these drivers are not in the upstream kernel. Are there common reasons why these drivers are not upstream? Dave cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 cpu or running memory? - does it cause bugs? - or are you just worried about evil modules? To clarify something here, by evil, don't necessarily think binary only. Out of tree modules are frequently using symbols that they shouldn't be. Because they get no peer-review here, they 'get away with it' for the most part. Until distro vendors push rebased kernel updates that removed exports that should never have been exported, and suddenly people like me get bombed with Fedora broke my xyz driver mails. ... The real problem is that these drivers are not in the upstream kernel. You're preaching to the choir. Are there common reasons why these drivers are not upstream? It varies case by case. Dave -- http://www.codemonkey.org.uk - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 right away. Which modules doing or smelling of TOE do work with unmodified vendor kernels? AFAIR TOE was both not a module and required some hooks in the network stack, so it's completely outside the scope of this thread. rick jones cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 patches were people are using internal APIs they shouldn't? With my Enterprise hat on, I can see where Andi was coming from originally. Just like we do in RHEL, SuSE have a concept of a kernel ABI and we too have a concept of a whitelist of symbols - a subset of kernel ABI that is approved for use by third parties (this is nothing to do with licensing, this is to do with ABI stability we try to ensure). As part of figuring out what should and should not be used by external modules (outside of the core kernel), we've gained a bit of experience, and it would be nice to be able to help others - this is nothing to do with upstream ABI stability, but just to be of a public service by documenting those functions that are never intended for modules but which necessarily are exported because they have one or two users. , makes it easier to communicate please don't use that API to module authors, 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. I suggested this exact idea privately at OLS. I still think it's the best compromise, though I like bits of the namespace idea. An EXPORT_SYMBOL_INTERNAL would indeed be trivial. Jon. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 motivation. This is why I didn't even mention that in the original patch description. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 driver that happened to get caught at the wrong end of the colorspace-conversion-in-kernel bunfight in the V4L playpen. Somebody wants to figure out how to get the gspca drivers into the kernel, they're at http://mxhaard.free.fr/download.html waiting for attention. ;) (Don't look at *me*, I don't understand the code, or the bunfight - I just happen to have one of the 244 supported webcams, and it works with that driver) pgp71FKUdkLqz.pgp Description: PGP signature
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 useful for the ABI stability issues too, but it was really not my primary motivation. This is why I didn't even mention that in the original patch description. Since ipv6 can never be removed because it references itself, the whole concept of a modular ipv6 is flawed. Sometime ago a patch was sent to remove the ipv6 module unload hooks but as I recall Dave rejected it believing the unload code could be fixed. -- Stephen Hemminger [EMAIL PROTECTED] - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 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 motivation. This is why I didn't even mention that in the original patch description. Since ipv6 can never be removed because it references itself, the whole concept AFAIK that is obsolete anyways. It was done because it was feared it would be broken, but at least the broken cases I knew about were all fixed a long time ago. Most likely it could be safely removed. 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 that is popular workaround for the common DNS server eats queries and causes delays issue. Forcing the user to rebuild the kernel for this wouldn't be practical. If ipv6 wasn't modular that would be hard to do. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 TOE comes to mind right away. Which modules doing or smelling of TOE do work with unmodified vendor kernels? At the very real risk of further demonstrating my Linux vocabulary limitations, I believe there is a Linux Sockets Acceleration module/whatnot for NetXen and related 10G NICs, and a cxgb3_toe (?) module for Chelsio 10G NICs. rick jones - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 empty set. - making it obvious to developers when they are binding their implementation to a particular kernel release See, there's your problem. All interfaces can, and will, change. You're always binding yourself to a particular release. So you're not proposing we mark what's not stable, you're arguing that we create a subset which is stable. That's an argument we're not (yet) having. Cheers, Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 ABIs for enterprise distributions easier [Yes I know that is not a popular topic on l-k, but it's a day-to-day problem for these distros and out of tree solutions do not work] That's a real problem, and I sympathise with the idea of marking symbols as externally useful (or, practically, mark internal). But we now need to decide what's externally useful. The currently line for exports is simple: someone in-tree needs it. You dislike the suggestion to extend this to if more than one in-tree needs it it's open. Currently your criterion seems to be does the maintainer hate external modules? which I don't think will be what you want... Cheers, Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 (internal, not supported). But the former is currently an empty set. Yes, I overstated this. - making it obvious to developers when they are binding their implementation to a particular kernel release See, there's your problem. All interfaces can, and will, change. You're always binding yourself to a particular release. Absolutely in the limit. But there are many bits of code that work quite nicely from release to release because they use services that live in the smooth water in the wake of the Linux head. I think defining that smooth water has merit. I also think that it would be nice to limit the scope of module externs to avoid polluting the global namespace. I'm not sure that this particular patch reaches these goals, but it prompted me to comment. So you're not proposing we mark what's not stable, you're arguing that we create a subset which is stable. Well, this is an interesting question. The answer is I think both are important. It would be nice (and arguably necessary long term) to limit the scope of externs. This can be accomplished with name spaces I want bob's implementation of read. I think it also has value to define interfaces that are considered stable (but not inviolate) to allow developers to make better informed decisions when choosing interfaces. Having this info explicit in the code seems logical to me. That's an argument we're not (yet) having. Yeah, maybe I'm off in the weeds on this one... Tom Cheers, Rusty. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 udp_* functions if they're not in the udp > > > namespace. > > > > I don't understand why you're so opposed to organizing the kernel's > > exported symbols in a more self-documenting way. > > No, I was the one who moved exports near their declarations. That's > organised. I just don't see how this new "organization" will help: oh good, > I won't accidentally use the udp functions any more?!? > > > 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 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? > > , makes it > > easier to communicate "please don't use that API" to module authors, > > 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. > > and takes at least a small step towards bringing the kernel's exported > > API under control. > > There is no "exported API" to bring under control. Hmm...apparently, there are those that are struggling... > There are symbols we > expose for the kernel's own use which can be used by external modules at > their own risk. > > > What's the real downside? > > 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 implementation (internal, not supported). > > Let's not put code in the core because "it doesn't seem to hurt". > agreed. > I'm sure you think there's a real problem, but I'm still waiting for someone > to *show* it to me. Then we can look at solutions. I think the benefits should include: - forcing developers to identify their exports as part of the implementation or as part of the kernel API - making it easier for reviewers to identify when developers are adding to the kernel API and thereby focusing the appropriate level of review to the new function - making it obvious to developers when they are binding their implementation to a particular kernel release > Rusty. > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 don't understand why you're so opposed to organizing the kernel's > exported symbols in a more self-documenting way. No, I was the one who moved exports near their declarations. That's organised. I just don't see how this new "organization" will help: oh good, I won't accidentally use the udp functions any more?!? > 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 patches were people are using internal APIs they shouldn't? > , makes it > easier to communicate "please don't use that API" to module authors, 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. > and takes at least a small step towards bringing the kernel's exported > API under control. There is no "exported API" to bring under control. There are symbols we expose for the kernel's own use which can be used by external modules at their own risk. > What's the real downside? No. That's the wrong question. What's the real upside? Let's not put code in the core because "it doesn't seem to hurt". I'm sure you think there's a real problem, but I'm still waiting for someone to *show* it to me. Then we can look at solutions. Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 useful -- they are only useful by a certain small > > > class of modules. > > > > If it is so clear, you should be able to easily provide examples? > > Sure -- Andi's example of symbols required only by TCP congestion > modules; Exactly. Why exactly should someone not write a new TCP congestion module? > the SCSI internals that Christoph wants to mark He didn't justify those though, either. > ; the symbols exported by my mlx4_core driver (which I admit are > currently only used > by the mlx4_ib driver, but which will also be used by at least the > ethernet NIC driver for the same hardware). Right. So presumably there will only ever be two drivers using this core code, so no new users will ever be written? Now we've found one use case, is it worth the complexity of namespaces? Is it worth the halfway point of export-to-module? What problem will it solve? > I thought this was > already covered repeatedly in the thread and indeed in Andi's code so > there was no need to repeat it... No, we've seen the solution and various people applying it. I'm still trying to discover the problem it's solving. Hope that helps, Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
> 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 global names still have to be unique > - still have to handle the "non-modular build" namespace conflicts > - there isn't a big problem with conflicting symbols today. Perhaps changing the name from "namespace" to "interface" would help? Then a module could have something like MODULE_USE_INTERFACE(foo); and I think that makes it clearer what the advantage of this is: it marks symbols as being part of a certain interface, requires modules that use that interface to declare that use explicitly, and allows reviewers to say "Hey why is this code using the scsi interface when it's a webcam driver?" - R. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 allowed to import symbols for it; all others > > > can't use the symbols. > > > > > > It adds two new macros: > > > > > > MODULE_NAMESPACE_ALLOW(namespace, module); > > > > I definitely like the idea of organizing exported symbols into > > namespaces. However, I feel like it would make more sense to have > > something like > > > > MODULE_NAMESPACE_IMPORT(namespace); > > 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. > > For better or worse, this is not C++. > 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 global names still have to be unique - still have to handle the "non-modular build" namespace conflicts - there isn't a big problem with conflicting symbols today. So why bother adding complexity. -- Stephen Hemminger <[EMAIL PROTECTED]> - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 allowed to import symbols for it; all others can't use the symbols. It adds two new macros: MODULE_NAMESPACE_ALLOW(namespace, module); I definitely like the idea of organizing exported symbols into namespaces. However, I feel like it would make more sense to have something like MODULE_NAMESPACE_IMPORT(namespace); 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. For better or worse, this is not C++. 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 global names still have to be unique - still have to handle the non-modular build namespace conflicts - there isn't a big problem with conflicting symbols today. So why bother adding complexity. -- Stephen Hemminger [EMAIL PROTECTED] - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 global names still have to be unique - still have to handle the non-modular build namespace conflicts - there isn't a big problem with conflicting symbols today. Perhaps changing the name from namespace to interface would help? Then a module could have something like MODULE_USE_INTERFACE(foo); and I think that makes it clearer what the advantage of this is: it marks symbols as being part of a certain interface, requires modules that use that interface to declare that use explicitly, and allows reviewers to say Hey why is this code using the scsi interface when it's a webcam driver? - R. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 useful -- they are only useful by a certain small class of modules. If it is so clear, you should be able to easily provide examples? Sure -- Andi's example of symbols required only by TCP congestion modules; Exactly. Why exactly should someone not write a new TCP congestion module? the SCSI internals that Christoph wants to mark He didn't justify those though, either. ; the symbols exported by my mlx4_core driver (which I admit are currently only used by the mlx4_ib driver, but which will also be used by at least the ethernet NIC driver for the same hardware). Right. So presumably there will only ever be two drivers using this core code, so no new users will ever be written? Now we've found one use case, is it worth the complexity of namespaces? Is it worth the halfway point of export-to-module? What problem will it solve? I thought this was already covered repeatedly in the thread and indeed in Andi's code so there was no need to repeat it... No, we've seen the solution and various people applying it. I'm still trying to discover the problem it's solving. Hope that helps, Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 don't understand why you're so opposed to organizing the kernel's exported symbols in a more self-documenting way. No, I was the one who moved exports near their declarations. That's organised. I just don't see how this new organization will help: oh good, I won't accidentally use the udp functions any more?!? 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 patches were people are using internal APIs they shouldn't? , makes it easier to communicate please don't use that API to module authors, 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. and takes at least a small step towards bringing the kernel's exported API under control. There is no exported API to bring under control. There are symbols we expose for the kernel's own use which can be used by external modules at their own risk. What's the real downside? No. That's the wrong question. What's the real upside? Let's not put code in the core because it doesn't seem to hurt. I'm sure you think there's a real problem, but I'm still waiting for someone to *show* it to me. Then we can look at solutions. Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 udp_* functions if they're not in the udp namespace. I don't understand why you're so opposed to organizing the kernel's exported symbols in a more self-documenting way. No, I was the one who moved exports near their declarations. That's organised. I just don't see how this new organization will help: oh good, I won't accidentally use the udp functions any more?!? 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 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? , makes it easier to communicate please don't use that API to module authors, 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. and takes at least a small step towards bringing the kernel's exported API under control. There is no exported API to bring under control. Hmm...apparently, there are those that are struggling... There are symbols we expose for the kernel's own use which can be used by external modules at their own risk. What's the real downside? 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 implementation (internal, not supported). Let's not put code in the core because it doesn't seem to hurt. agreed. I'm sure you think there's a real problem, but I'm still waiting for someone to *show* it to me. Then we can look at solutions. I think the benefits should include: - forcing developers to identify their exports as part of the implementation or as part of the kernel API - making it easier for reviewers to identify when developers are adding to the kernel API and thereby focusing the appropriate level of review to the new function - making it obvious to developers when they are binding their implementation to a particular kernel release Rusty. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
> 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 kernel's exported symbols in a more self-documenting way. It seems pretty clear to me that having a mechanism that requires modules to make explicit which (semi-)internal APIs makes reviewing easier, makes it easier to communicate "please don't use that API" to module authors, and takes at least a small step towards bringing the kernel's exported API under control. What's the real downside? - R. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
> > 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 modules. > > If it is so clear, you should be able to easily provide examples? Sure -- Andi's example of symbols required only by TCP congestion modules; the SCSI internals that Christoph wants to mark; the symbols exported by my mlx4_core driver (which I admit are currently only used by the mlx4_ib driver, but which will also be used by at least the ethernet NIC driver for the same hardware). I thought this was already covered repeatedly in the thread and indeed in Andi's code so there was no need to repeat it... - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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. > > > > It adds two new macros: > > > > MODULE_NAMESPACE_ALLOW(namespace, module); > > I definitely like the idea of organizing exported symbols into > namespaces. However, I feel like it would make more sense to have > something like > > MODULE_NAMESPACE_IMPORT(namespace); 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. For better or worse, this is not C++. Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 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 modules. If it is so clear, you should be able to easily provide examples? Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 reviewing, this won't make them review. I don't think > > the > > With millions of LOC the primary maintainers cannot review everything. > It's not that anybody is doing a bad job -- it is just so much code > that explicit mechanisms are better than implicit contracts. > > > problem is that people are conniving to avoid review. > > No of course not -- it is just too much code to let everything > be reviewed by the core subsystem maintainers. But with explicit > marking of internal symbols they would need to look at it because > the relationship will be clearly spelled out in the code. No, a one-line patch adding the module to the set is all they'd see. There's no reason to think this will cause more review. > > > 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? > > Out of tree solutions generally do not scale. Nobody else can > keep up with 2+ Million changes each merge window. > > > If a symbol has more than one in-tree user, it's hard to argue against an > > There are still classes of drivers. e.g. for the SCSI example: SD,SG,SR > etc. are more internal while low level drivers like aic7xxx are clearly > external drivers. Then mark those symbols internal and only allow concurrently-built modules to access them. That's simpler and requires much less maintenance than your solution. > > out-of-tree module using the symbol, unless you're arguing against *all* > > out-of-tree modules. > > No, actually namespaces kind of help out of tree modules. Once they only > use interfaces that are really generic driver interfaces and fairly stable > their authors will have much less pain forward porting to newer kernel > version. But currently the authors cannot even know what is an instable > internal interface and what is a generic relatively stable driver level > interface. Namespaces are a mechanism to make this all explicit. So in your head you have a notion of a kernel API, and you're trying to make that API explicit in the code. Sorry, but no. Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
> 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 are used by multiple modules but which are not generically useful -- they are only useful by a certain small class of modules. - R. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
> 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(namespace, module); I definitely like the idea of organizing exported symbols into namespaces. However, I feel like it would make more sense to have something like MODULE_NAMESPACE_IMPORT(namespace); inside the modules that use a namespace. This matches the way C preprocessor #includes, C++ namespaces, perl "use", etc. works and so it is probably closer to how programmers think. It does weaken the enforcement of review a little bit, since there are no changes to the site where things are exported to catch, but git makes it easy to sneak that kind of change in anyway. The practical benefits are that you don't end up with stupid patch conflicts caused by one patch adding MODULE_NAMESPACE_ALLOW() for module "foo" and another patch adding it for module "bar" at the same place, and that it becomes simpler for people to test or deliver, say, a new TCP congestion module without having to rebuild the whole kernel (which is an especially huge pain for distro kernels). In any case I would make use of this in whatever form it gets merged in -- Mellanox ConnectX hardware can operate simultaneously as an InfiniBand adapter and a 10Gb ethernet NIC, and so my driver is split up into a low-level mlx4_core driver that exports symbols for other mlx4 drivers to use; clearly it only makes sense to export them to other parts of the driver, and in this case the difference between "ALLOW" and "IMPORT" semantics is not a big deal. - R. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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(namespace, module); I definitely like the idea of organizing exported symbols into namespaces. However, I feel like it would make more sense to have something like MODULE_NAMESPACE_IMPORT(namespace); inside the modules that use a namespace. This matches the way C preprocessor #includes, C++ namespaces, perl use, etc. works and so it is probably closer to how programmers think. It does weaken the enforcement of review a little bit, since there are no changes to the site where things are exported to catch, but git makes it easy to sneak that kind of change in anyway. The practical benefits are that you don't end up with stupid patch conflicts caused by one patch adding MODULE_NAMESPACE_ALLOW() for module foo and another patch adding it for module bar at the same place, and that it becomes simpler for people to test or deliver, say, a new TCP congestion module without having to rebuild the whole kernel (which is an especially huge pain for distro kernels). In any case I would make use of this in whatever form it gets merged in -- Mellanox ConnectX hardware can operate simultaneously as an InfiniBand adapter and a 10Gb ethernet NIC, and so my driver is split up into a low-level mlx4_core driver that exports symbols for other mlx4 drivers to use; clearly it only makes sense to export them to other parts of the driver, and in this case the difference between ALLOW and IMPORT semantics is not a big deal. - R. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 are used by multiple modules but which are not generically useful -- they are only useful by a certain small class of modules. - R. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 reviewing, this won't make them review. I don't think the With millions of LOC the primary maintainers cannot review everything. It's not that anybody is doing a bad job -- it is just so much code that explicit mechanisms are better than implicit contracts. problem is that people are conniving to avoid review. No of course not -- it is just too much code to let everything be reviewed by the core subsystem maintainers. But with explicit marking of internal symbols they would need to look at it because the relationship will be clearly spelled out in the code. No, a one-line patch adding the module to the set is all they'd see. There's no reason to think this will cause more review. 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? Out of tree solutions generally do not scale. Nobody else can keep up with 2+ Million changes each merge window. If a symbol has more than one in-tree user, it's hard to argue against an There are still classes of drivers. e.g. for the SCSI example: SD,SG,SR etc. are more internal while low level drivers like aic7xxx are clearly external drivers. Then mark those symbols internal and only allow concurrently-built modules to access them. That's simpler and requires much less maintenance than your solution. out-of-tree module using the symbol, unless you're arguing against *all* out-of-tree modules. No, actually namespaces kind of help out of tree modules. Once they only use interfaces that are really generic driver interfaces and fairly stable their authors will have much less pain forward porting to newer kernel version. But currently the authors cannot even know what is an instable internal interface and what is a generic relatively stable driver level interface. Namespaces are a mechanism to make this all explicit. So in your head you have a notion of a kernel API, and you're trying to make that API explicit in the code. Sorry, but no. Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 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 modules. If it is so clear, you should be able to easily provide examples? Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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. It adds two new macros: MODULE_NAMESPACE_ALLOW(namespace, module); I definitely like the idea of organizing exported symbols into namespaces. However, I feel like it would make more sense to have something like MODULE_NAMESPACE_IMPORT(namespace); 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. For better or worse, this is not C++. Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 modules. If it is so clear, you should be able to easily provide examples? Sure -- Andi's example of symbols required only by TCP congestion modules; the SCSI internals that Christoph wants to mark; the symbols exported by my mlx4_core driver (which I admit are currently only used by the mlx4_ib driver, but which will also be used by at least the ethernet NIC driver for the same hardware). I thought this was already covered repeatedly in the thread and indeed in Andi's code so there was no need to repeat it... - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 kernel's exported symbols in a more self-documenting way. It seems pretty clear to me that having a mechanism that requires modules to make explicit which (semi-)internal APIs makes reviewing easier, makes it easier to communicate please don't use that API to module authors, and takes at least a small step towards bringing the kernel's exported API under control. What's the real downside? - R. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 be the only > > enforcement mechanism for this anymore. > > If people aren't reviewing, this won't make them review. I don't think the With millions of LOC the primary maintainers cannot review everything. It's not that anybody is doing a bad job -- it is just so much code that explicit mechanisms are better than implicit contracts. > problem is that people are conniving to avoid review. No of course not -- it is just too much code to let everything be reviewed by the core subsystem maintainers. But with explicit marking of internal symbols they would need to look at it because the relationship will be clearly spelled out in the code. > > 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? Out of tree solutions generally do not scale. Nobody else can keep up with 2+ Million changes each merge window. > > If a symbol has more than one in-tree user, it's hard to argue against an There are still classes of drivers. e.g. for the SCSI example: SD,SG,SR etc. are more internal while low level drivers like aic7xxx are clearly external drivers. > out-of-tree module using the symbol, unless you're arguing against *all* > out-of-tree modules. No, actually namespaces kind of help out of tree modules. Once they only use interfaces that are really generic driver interfaces and fairly stable their authors will have much less pain forward porting to newer kernel version. But currently the authors cannot even know what is an instable internal interface and what is a generic relatively stable driver level interface. Namespaces are a mechanism to make this all explicit. -Andi - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 be the only enforcement mechanism for this anymore. If people aren't reviewing, this won't make them review. I don't think the With millions of LOC the primary maintainers cannot review everything. It's not that anybody is doing a bad job -- it is just so much code that explicit mechanisms are better than implicit contracts. problem is that people are conniving to avoid review. No of course not -- it is just too much code to let everything be reviewed by the core subsystem maintainers. But with explicit marking of internal symbols they would need to look at it because the relationship will be clearly spelled out in the code. 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? Out of tree solutions generally do not scale. Nobody else can keep up with 2+ Million changes each merge window. If a symbol has more than one in-tree user, it's hard to argue against an There are still classes of drivers. e.g. for the SCSI example: SD,SG,SR etc. are more internal while low level drivers like aic7xxx are clearly external drivers. out-of-tree module using the symbol, unless you're arguing against *all* out-of-tree modules. No, actually namespaces kind of help out of tree modules. Once they only use interfaces that are really generic driver interfaces and fairly stable their authors will have much less pain forward porting to newer kernel version. But currently the authors cannot even know what is an instable internal interface and what is a generic relatively stable driver level interface. Namespaces are a mechanism to make this all explicit. -Andi - 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/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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. > Anything which is kind of internal > should only be used by closely related in tree modules which can be > updated. Is there evidence that this is a problem for us? Are there any interfaces you've restricted so far which are causing problems? > Point of is not to be some kind of license enforcer or similar, > there are already other mechanisms for that. Just to get the set of really > public kernel interfaces down to a manageable level. Why do we care what a "really public"? We treat them all the same, as changeable interfaces. ie. None of them are "really public". For example, you put all the udp functions in the "udp" namespace. But what have we gained? What has become easier to maintain? All those function start with "udp_": are people having trouble telling what they're for? If you really want to reduce "public interfaces" then it's much simpler to mark explicitly what out-of-tree modules can use. We can have a list of symbol names in include/linux/public-exports.h. I just don't see what problems this separation solves. Rusty. - 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/lkml/
Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
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 struct > > device_driver? If it's possible then it will not limited to modules. > > Not sure I follow you. Can you expand? > I know little about module internal, so if I'm wrong please just don't mind, please point out or just ignore. Kernel symbols could apply to kernel object model, doesn't it? I just think that because the device_driver have a mod_name member (for built-in module), so if something can be done as device driver is registered. - 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/lkml/
