On Tue, 2013-02-12 at 20:43 +0000, Al Viro wrote: > I don't know and TBH I'm rather dubious about that. In the end, it's a > simple question of cost-shifting; people with scripts that use tracepoints > vs. people working with the code those tracepoints are in. And as far as > I'm concerned, the only acceptable situation is when *all* the price is > paid by the former. It works for exports and it works for modules; out-of-tree > code is protected only by the amount of work needed to modify the in-tree > code depending on the same things. And if we decide that changing all > in-tree users of something is not too costly, that's it - out-of-tree folks > might ask for help coping with the resulting change, they might try to > explain why that change is a bad idea if they notice it being discussed before > it goes in, but they have no veto power. There's your answer! I can create tracepoints that will not show up to userspace. Then I can write an out of tree module, that will find these "internal" tracepoints and this module will make them visible to usespace. Anyone that wants these tracepoints will have to compile and load my module. The trick is, I will never submit this module to be included into mainline. Sure, a distro could load this by default, but it would be no different than any other out of tree module. They would have no veto power over changes to these tracepoints. I mean come on. If we go so far as to have kernel developers use an out of tree / never to be included module to have access to these tracepoints. We can not be held liable for changes to them anymore than we make other module ABI incompatible changes. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
