On Wed, Nov 5, 2014 at 3:09 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: >> You know, this use case seems unavoidable so I'll just proceed with the >> configurability of it. But note that it seems we're both in agreement >> that right now what you described requires more work before in any way >> shape or form folks start using it for the exact purpose you described. >> I also think Andi Kleen's module namespace might be a much better solution to >> that problem [0], we'd just have to carry the code ourselves as I am not > > Just to clarify. My name spaces didn't really provide different > name spaces (like C++), it just added a ACL to exports to make it possible > to do "export only to module N". But the name space itself > was still flat Indeed that is how I understood it and the use case in mind for backporting different subsystems from different future versions of Linux to an older one might be a use case here (although insane). > On the linker side doing real name spaces is probably not too hard, > but it would be difficult for linked in code without special linker > support. Good to know, perhaps useful for folks who really do consider embarking on this strategy with backports (although I don't recommend it). >> sure if this is ever going to get upstream as it was originally nacked. > > May need to revisit that. The only thing that was not clear to me from reviewing the module namespace stuff a while ago was the original intent, but I confess I actually only looked at the technical details to see if it was applicable to the backports case, do you recall the original motivation ? Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
