Messages in this thread | | | Date | Thu, 22 Jan 2015 10:15:30 -0500 | From | Steven Rostedt <> | Subject | Re: [RFC][PATCH 0/5] tracing: Add new file system tracefs |
| |
On Thu, 22 Jan 2015 09:55:47 -0500 Tejun Heo <tj@kernel.org> wrote:
> kernfs provides two sets of file operations. One is seq_file based > and the other is direct read/write. In both cases, bouncing data > between userland and kernel is handled by kernfs. If you already have > existing read write ops implemented doing custom buffer handling and > direct userland memory access, it'll take some adaptation but for a > lot of cases this would consolidate duplicate code paths.
Does it also handle splice? That's a key part of the tracing code.
Almost every tracing file is somewhat unique. When things can be shared, they are, but there's not much generic code that can be shared.
> > > I created tracefs with 700 lines of code and two files (inode.c and > > tracefs.h), and for the users of tracefs, I just did > > s/debugfs/tracefs/. If I can't make that substitution for the users, > > that is a show stopper. > > > > I don't see how I can use kernfs without it causing a lot of invasive > > changes to the ftrace subsystem. > > Converting an existing vfs based pseudo fs implementation over to > kernfs isn't trivial. I mean, if that were trivial, why would kernfs > even exist? kernfs is a layer which abstracts a large part of pseudo > filesystem which provides extra features like significantly lower > memory footprint with large number of nodes and revocation support in > a way that its users, for the most part, hopefully, only have to worry > about the content to provide to userland.
Sounds like some of the tracing files could benefit from this. But I'm not sure kernfs has all the necessary features I need.
> > I frankly have no idea whether tracefs would be a good candidate for > kernfs usage but if you're looking for a mechanical one-to-one > conversion from vfs based implementation, that's not gonna work.
OK, thanks. Perhaps if tracing was still new I could have tried to go with kernfs. But as debugfs was such a simple to use interface, it let me concentrate more on the complexities of tracing itself instead of spending time coming up with a complex interface.
If a one to one conversion to vfs is not gonna work, I'm going to be interested in seeing how debugfs will be converted.
Anyway, I think I'm convinced that kernfs is not yet the way to go. I'm going to continue on with my current path.
Thanks,
-- Steve
| |