Messages in this thread | | | Date | Thu, 22 Oct 2009 21:27:54 -0700 | From | Greg KH <> | Subject | Re: [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
| |