From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC] Hack to use mkdir/rmdir in debugfs
Date: Tue, 22 Jan 2013 20:41:46 -0800 [thread overview]
Message-ID: <20130123044146.GA3079@kroah.com> (raw)
In-Reply-To: <1358915495.21576.102.camel@gandalf.local.home>
On Tue, Jan 22, 2013 at 11:31:35PM -0500, Steven Rostedt wrote:
> On Tue, 2013-01-22 at 20:08 -0800, Greg Kroah-Hartman wrote:
>
> > > Is doing something as silly as the following fine, or is there a better
> > > way?
> >
> > Yes, why not create your own fs for ftrace? :)
>
> But but but...
>
> debugfs is soooo convenient!
>
> Do you think it would be worth doing that though? I only need the mkdir
> and rmdir for this one instance. Nothing more.
>
> > > mutex_unlock(&inode->i_mutex);
> > >
> > > ret = new_instance_create(dentry->d_iname);
> > >
> > > mutex_lock(&inode->i_mutex);
> > >
>
> > But how can you callback to your code to let it know that something was
> > created in it?
>
> I pass the dentry->d_iname to create a directory.
>
> >
> > Don't you need that for both mkdir and rmdir?
>
> It's a global list. It's very specific and doesn't need to be robust. It
> all deals with modifying one global parameter. Not that hard. And I've
> already implemented this. It works quite well :-)
>
> >
> > But again, I'd really not want to do this in debugfs, how about your own
> > filesystem?
>
> I will note that this never modifies the debugfs code. But it does
> circumvent it.
Ah, I like circumventing debugfs, it kind of fits right into its mission :)
> That is, all this code lives in kernel/trace/trace.c. I don't modify
> any of the debugfs code. I just replace the debugfs
> dentry->d_inode->i_op with my own ops.
Oh, ok, I thought you were talking about modifying the debugfs core.
> I can create my own fs, but that just seems to be overkill. The only
> difference is that I need mkdir and rmdir for this one instance.
>
> That said, perhaps it wouldn't be too hard to create a ftracefs. Where
> should it go? fs/ftrace or perhaps kernel/trace/fs ?
Sure, it only takes 300 lines to write a fs so it's not hard to do your
own.
> I notice that I only use:
>
> debugfs_create_file()
> debugfs_remove();
> debugfs_create_dir();
> debugfs_remove_recursive();
> debugfs_initialized()
>
> so maybe it wouldn't be such a far fetch thing to implement.
>
> But then would I be able to still mount it in /debug/tracing ? As this
> is where everything currently uses it? But then we need to teach admins
> to add it there, or someplace else. /sys/kernel/ftrace?
>
> Tools like trace-cmd and perf already expect it to be in the debugfs
> tracing directory, and will automate mounting it to /sys/kernel/debug/
> if not found. This may break userspace if I make another fs.
Yes, you would need to require distros to mount it in the proper place,
which is a pain, but not impossible. It's up to you, as I thought you
needed to modify debugfs, I didn't like it, but if you can do it in your
own code, I really don't care anymore :)
greg k-h
next prev parent reply other threads:[~2013-01-23 4:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 3:01 [RFC] Hack to use mkdir/rmdir in debugfs Steven Rostedt
2013-01-23 3:47 ` Steven Rostedt
2013-01-23 4:08 ` Greg Kroah-Hartman
2013-01-23 4:31 ` Steven Rostedt
2013-01-23 4:41 ` Greg Kroah-Hartman [this message]
2013-01-23 4:52 ` Steven Rostedt
2013-01-23 4:44 ` Steven Rostedt
2013-01-23 4:48 ` Steven Rostedt
2013-01-23 4:55 ` Greg Kroah-Hartman
2013-01-23 5:05 ` Steven Rostedt
2013-01-24 22:39 ` Valdis.Kletnieks
2013-01-24 23:53 ` Steven Rostedt
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=20130123044146.GA3079@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.