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/
