From: Greg KH <greg@kroah.com>
To: "Paul E. McKenney" <paulmck@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, dipankar@in.ibm.com,
vatsa@in.ibm.com, rusty@au1.ibm.com, mingo@elte.hu,
manfred@colorfullife.com
Subject: Re: [PATCH] RCU torture testing
Date: Mon, 3 Oct 2005 07:48:56 -0700 [thread overview]
Message-ID: <20051003144856.GB7432@kroah.com> (raw)
In-Reply-To: <20051003142810.GA1300@us.ibm.com>
On Mon, Oct 03, 2005 at 07:28:10AM -0700, Paul E. McKenney wrote:
> On Sat, Oct 01, 2005 at 05:11:37PM -0700, Greg KH wrote:
> > On Sat, Oct 01, 2005 at 11:20:56AM -0700, Paul E. McKenney wrote:
> > > +The CONFIG_RCU_TORTURE_TEST config option is available for all RCU
> > > +implementations. It makes three /proc entries available, namely: rcutw,
> > > +rcutr, and rcuts.
> >
> > Ick, why /proc entries, this has nothing to do with processes, right?
> > Please use debugfs instead, that is what it was created for.
>
> OK, will look into that. At first glance, it does appear to require
> quite a bit more code to make use of than did the /proc filesystem,
I wasn't going for "least lines of code" here, like I did for sysfs.
Although if you do have a "simple" datatype, it's less code than for
procfs.
> if you want the files to produce human-readable strings, as is appropriate
> in this case. I am looking at uhci-debug.c -- is there an example that
> better matches what I am trying to do?
Just provide a "read" function, that's exactly what people do for proc
these days, it shouldn't be tough to switch over.
thanks,
greg k-h
next prev parent reply other threads:[~2005-10-03 14:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-01 18:20 [PATCH] RCU torture testing Paul E. McKenney
2005-10-02 0:11 ` Greg KH
2005-10-03 14:28 ` Paul E. McKenney
2005-10-03 14:48 ` Greg KH [this message]
2005-10-02 21:05 ` Pavel Machek
2005-10-03 6:30 ` Ingo Molnar
2005-10-03 14:30 ` Paul E. McKenney
2005-10-03 14:36 ` Arjan van de Ven
2005-10-03 15:26 ` Paul E. McKenney
2005-10-03 15:31 ` Arjan van de Ven
2005-10-03 15:49 ` Paul E. McKenney
2005-10-22 23:09 ` Paul E. McKenney
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=20051003144856.GB7432@kroah.com \
--to=greg@kroah.com \
--cc=akpm@osdl.org \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=mingo@elte.hu \
--cc=paulmck@us.ibm.com \
--cc=rusty@au1.ibm.com \
--cc=vatsa@in.ibm.com \
/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.