Re: [PATCH 1/2] vfs: make fcheck_files() an exported functions

[Al Viro <viro@ZenIV.linux.org.uk>]

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...