Re: [RFC] tracefs

[Greg KH]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/