Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro. | Date | Sat, 24 Nov 2007 15:53:34 +1100 |
| |
On Saturday 24 November 2007 06:53:30 Andi Kleen wrote: > This serves as a documentation > on what is considered internal. And if some obscure module (in or > out of tree) wants to use an internal interface they first have > to send the module maintainer a patch and get some review this way.
So, you're saying that there's a problem with in-tree modules using symbols they shouldn't? Can you give an example?
> I believe that is fairly important in tree too because the > kernel has become so big now that review cannot be the only > enforcement mechanism for this anymore.
If people aren't reviewing, this won't make them review. I don't think the problem is that people are conniving to avoid review.
> Another secondary reason is that there are too many exported interfaces > in general.
Probably, but this doesn't reduce it.
> Several distributions have policies that require to > keep the changes to these exported interfaces minimal and that > is very hard with thousands of exported symbol. With name spaces > the number of truly publicly exported symbols will hopefully > shrink to a much smaller, more manageable set.
*This* makes sense. But it's not clear that the burden should be placed on kernel coders. You can create a list yourself. How do I tell the difference between "truly publicly exported" symbols and others?
If a symbol has more than one in-tree user, it's hard to argue against an out-of-tree module using the symbol, unless you're arguing against *all* out-of-tree modules.
Sorry, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |