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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[ Added Ingo and Linus ]

On Tue, 2013-02-12 at 09:41 -0800, Tejun Heo wrote:
> Hey, Al.
> 
> On Sun, Feb 10, 2013 at 12:18:12AM +0000, Al Viro wrote:
> > > Andrew, can you please pick up these two patches?  They were posted a
> > > month ago and at least nobody seems violently against them.  The
> > > original patches are,
> > 
> > Consider *any* tracepoints in that area blanketly NAKed.  Sorry, I thought
> > I made it clear, but just in case:
> 
> Heh, this is the first time I hear about it.
> 
> > As far as I'm concerned, *the* *only* interface stability warranties in VFS
> > are those for syscalls.  Which means that no tracepoints are going to be
> > acceptable there.  End of story.
> 
> 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?

-- Steve

> 
> Anyways, I haven't looked at the tracer code for a while, and am not
> sure whether the information can be acquired differently.  Will take
> another look.
> 
> Thanks.
> 


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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux