On Thu, 22 Jan 2015 09:55:47 -0500 Tejun Heo <t...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
