From: Tejun Heo <tj@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>,
Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC][PATCH 0/5] tracing: Add new file system tracefs
Date: Thu, 22 Jan 2015 09:55:47 -0500 [thread overview]
Message-ID: <20150122145547.GB4507@htj.dyndns.org> (raw)
In-Reply-To: <20150122093249.6f4041a8@gandalf.local.home>
Hey, Steven.
On Thu, Jan 22, 2015 at 09:32:49AM -0500, Steven Rostedt wrote:
> The problem is that these do not return dentry. They return kernfs_node.
Yeap, that's what represents a file or directory in kernfs.
> I see a kernfs_node_from_dentry() call but not the other way around.
Because dentries / inodes may or may not exist for a given kernfs
node. kernfs_nodes are the backing information in a similar way to an
actual filesystem.
> Yes, the interface for tracefs is just these four functions, but then
> the interaction of the kernfs versions use a completely different API.
>
> Each of the created files expects to attach their own open, read,
> write, and release functions. And yes, some even use the seq functions,
> and they use it the vfs way. I do not intend on rewriting the users of
> the debugfs file system. To use kernfs, it seems that I would need to
> do that, and I don't have the time to make such a dramatic change to
> the system. It will fall down on my TODO list and I probably wont get
> to it for another decade.
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.
> 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.
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.
Thanks.
--
tejun
next prev parent reply other threads:[~2015-01-22 14:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 17:19 [RFC][PATCH 0/5] tracing: Add new file system tracefs Steven Rostedt
2015-01-21 17:19 ` [RFC][PATCH 1/5] tracefs: Add new tracefs file system Steven Rostedt
2015-01-21 18:30 ` Steven Rostedt
2015-01-21 17:19 ` [RFC][PATCH 2/5] tracing: Convert the tracing facility over to use tracefs Steven Rostedt
2015-01-21 17:32 ` Steven Rostedt
2015-01-21 17:19 ` [RFC][PATCH 3/5] tracing: Automatically mount tracefs on debugfs/tracing Steven Rostedt
2015-01-21 17:19 ` [RFC][PATCH 4/5] tracing: Have mkdir and rmdir be part of tracefs Steven Rostedt
2015-01-21 18:31 ` Steven Rostedt
2015-01-21 20:47 ` Steven Rostedt
2015-01-21 17:19 ` [RFC][PATCH 5/5] tracefs: Add directory /sys/kernel/tracing Steven Rostedt
2015-01-21 17:32 ` [RFC][PATCH 0/5] tracing: Add new file system tracefs Steven Rostedt
2015-01-21 23:00 ` Greg Kroah-Hartman
2015-01-22 1:47 ` Steven Rostedt
2015-01-22 3:07 ` Steven Rostedt
2015-01-22 3:18 ` Greg Kroah-Hartman
2015-01-22 3:51 ` Steven Rostedt
2015-01-22 12:32 ` Tejun Heo
2015-01-22 12:33 ` Tejun Heo
2015-01-22 14:32 ` Steven Rostedt
2015-01-22 14:55 ` Tejun Heo [this message]
2015-01-22 15:15 ` Steven Rostedt
2015-01-22 15:24 ` Tejun Heo
2015-01-22 4:23 ` Al Viro
2015-01-22 4:35 ` Steven Rostedt
2015-01-22 12:49 ` Tejun Heo
2015-01-22 12:26 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150122145547.GB4507@htj.dyndns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).