lkml.org 
[lkml]   [2009]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] tracefs
On Thu, Oct 22, 2009 at 09:10:30PM -0400, Steven Rostedt wrote:
> On Thu, 2009-10-22 at 17:49 -0700, Greg KH wrote:
> > Hi all,
> >
> > At LinuxCon this year, Steven and I talked about moving the debugfs
> > usage in the tracing core to a stand-alone filesystem to give the
> > ability to start to lock down the api so that people an count on what is
> > going on in the tracing userspace interface.
> >
> > So, on the flight to Tokyo for the kernel summit, I wrote up tracefs.
> > Here's the first very rough cut at it below. I've run it here on my
> > laptop, and all seems well, but I do have a few questions:
> > - I've made the mount point be /sys/kernel/trace/ Is that ok? Should
> > it be /sys/kernel/tracing/? Or something else? You get to pick the
> > mount point now, so I don't want to hear any more grumblings about
> > the location in the future :)
>
> /trace
>
> (rostedt hides)

Yeah, I knew you were going to do that :)

> > - the block tracing code was not changed, as it uses
> > /sys/kernel/debug/block/ at the moment, not the
> > /sys/kernel/debug/tracing/ directory. To change the block tracing
> > code, it would require us to change the userspace tools as well,
> > which I don't know if we want to do. Thanks to Jens for
> > straightening this all out for me, originally I thought it was a bug
> > in the block tracing code.
>
> I thought we were suppose to port the block tracing over to tracepoints
> anyway, and remove the "block" tracer?

That's between you and Jens, but at the kernel summit, he said it was
not going to go away any year soon.

> > - is this type of conversion to a custom virtual filesystem acceptable
> > to the other tracing developers? Any objection to not using debugfs
> > calls anymore? The operation is identical, but it keeps the rest of
> > the kernel from intruding on your space now.
>
> What I would like is to still use debugfs for new features until we
> understand them better. That location, files can disappear or have their
> formats completely changed. When things move to tracefs, then the API is
> a bit more rigid. Files can still change, but they must change in a way
> to be backward compatible. We need a nice way to document how a file can
> change, and stick to it.

That sounds like a very good idea. I'll respin the patch to only merge
one tracer over at a time.

You are going to have a bit of a difficult time if you mix debugfs and
tracefs as people will not know where to look for the files. But hey,
that's your problem to deal with :)

> [ Snip the s/debugfs/tracefs/ changes ]
>
> Note, as mentioned above. I envision having a way to start out in
> debugfs and then slowly move things over to tracefs when they become
> standardize. Think of debugfs as linux-next ;-)
>
> Although most of the files are pretty much stable, I don't want to do a
> cross the board change at the moment.

That sounds reasonable. Thanks for the review, I'll respin this when I
get back home next week.

thanks,

greg k-h


\
 
 \ /
  Last update: 2009-10-23 06:35    [W:1.295 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site