On Tue, Feb 12, 2013 at 01:21:48PM -0500, Steven Rostedt wrote: > [ Added Ingo and Linus ] > > I see, it's about API stability. This TP is expected to be used by > > internal tracer to approxmiately match generated IOs to specific > > files, so at least the proposed usage is inside the kernel. I suppose > > there's no way to mark TPs internal, Steven? > > We discussed this a couple of years ago at kernel summit, but for > various reasons it never got anywhere. > > https://lkml.org/lkml/2010/11/16/606 > > Perhaps the way to do this is to have certain tracepoints only appear > with a kernel parameter. Something like "enable_debug_tracepoints", > where distros will not have it enabled by default (the word "debug" > should scare them). And thus, tools should never use them. But for those > that need to debug systems, the kernel parameter can be added, and these > tracepoints will "magically" appear. > > I mean, do we have to support an ABI that requires a kernel parameter > set in order to use it? Actually, debug didn't scare them enough for > debugfs, maybe the parameter should be called: > "enable_unstable_tracepoints" That would be even scarier. Or have it be > "enable_tracepoints_but_do_not_expect_them_to_exist", but that wastes up > too much of the kernel parameter text. > > Hmm, this should be pretty ease to write up. Think that would work? 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. IOW, somebody showing up with "my out-of-tree module doesn't compile anymore, put those methods back, restore that export and move this mutex from struct bar back to struct foo" will get told to take a hike. Somebody showing up with "my userland tool relied on having event generated every time when this mutex had been taken on struct foo, with these fields of struct foo dumped into event" will have much stronger case when they get told that mutex got moved to struct bar which has no such fields and neither a way to get to equivalent information nor consistency warranties those pieces of data used to have under that mutex. Scary kernel options might suffice, but we had cases of userland Fine Piece Of Software growing a dependency on "optional" kernel-side FPOS, making it mandatory and leaving us to deal with the fallout. Pardon me the bluntness, but what's to stop the same people from doing the following: Step 1: randomly chosen unstable tracepoint becomes used by udev, if present Step 2: Fedora starts putting your scary kernel option into grub configs Step 3: udev (while swearing support for "legacy" setups lacking that option) gets more and more dependent on it; at that stage, any kernel-side change breaking the tracepoint in question would cause serious pain for $BIGNUM Fedora boxen out there Step 4: tracepoint in question is moved from unstable class to stable, because it's not feasible to change anymore without major userland breakage on a lot of existing systems Step 5: support of "legacy" setups disappears, at least on the boxen with sufficiently recent kernel versions. Lather, rinse, repeat... -- 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
