From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: jbaron@redhat.com, linux-kernel@vger.kernel.org, joe@perches.com,
greg@kroah.com, nick@nick-andrew.net, randy.dunlap@oracle.com
Subject: Re: [PATCH 2/7] dynamic debug v2 - nfs conversion
Date: Tue, 15 Jul 2008 19:44:52 -0400 [thread overview]
Message-ID: <1216165492.7981.105.camel@localhost> (raw)
In-Reply-To: <20080715162441.4aa011e0.akpm@linux-foundation.org>
On Tue, 2008-07-15 at 16:24 -0700, Andrew Morton wrote:
> On Tue, 15 Jul 2008 19:15:45 -0400
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> > On Tue, 2008-07-15 at 18:56 -0400, Trond Myklebust wrote:
> >
> > > The point is that he is changing a semi-official interface for tracing
> > > the NFS kernel activity from userspace. I'd like to know why and how it
> > > is being modified before I can ack it.
> > >
> > > In addition there are several other developers who have a daily interest
> > > in using this interface when helping our users, and who might have
> > > comments.
> >
> > OK. Having looked up the missing patch on gmane, I'd like to know
> > whether or not there is a followup plan to fix up utilities like
> > 'rpcdebug'? Apparently this patch doesn't remove the existing sunrpc
> > sysctl interface, but does circumvent it. The result is that while
> > rpcdebug will happily continue to run, it just won't work any more...
> >
>
> I'm suspecting that Jason chose the wrong starter subsystem here ;)
> Probably we should have started with the many hundreds of simpler
> cases.
>
> OTOH, it's important that Jason understand NFS's requirements here.
> Treat it as a testcase for his design. Will his infrastructure be
> usable by NFS? If not, does his infrastructure need generalising and
> strengthening so that it _does_ suit?
Since rpcdebug + the sysctl interface are well established interfaces
that are probably scripted all over the place by administrators who are
using it to as a debugging tool, I'd say that any interface breakages
need a managed transition period.
IOW: I'd say that any changes are going to need a transition period
where a compatibility mode can be compiled in and where both interfaces
work. It doesn't have to be too sophisticated, perhaps just something
along the lines of
+# define ifdebug(fac) if (dynamic_dbg_enabled(TYPE_FLAG, \
+ RPCDBG_##fac,\
+ rpc_debug) || \
+ unlikely(rpc_debug & RPCDBG_##fac))
+# define dfprintk(fac, args...) do { ifdebug(fac) printk(args); } while(0)
So that scripts can choose either interface, and still continue to operate.
Please also note the 'special' command
echo "n" >/proc/sys/sunrpc/rpc_debug
(where "n" is an integer) which always triggers a listing of the
currently executing rpc calls (see net/sunrpc/sysctl.c:proc_dodebug())
in addition to enabling/disabling debugging.
next prev parent reply other threads:[~2008-07-15 23:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 21:32 [PATCH 2/7] dynamic debug v2 - nfs conversion Jason Baron
2008-07-15 22:30 ` Trond Myklebust
2008-07-15 22:43 ` Andrew Morton
2008-07-15 22:56 ` Trond Myklebust
2008-07-15 23:08 ` Andrew Morton
2008-07-15 23:15 ` Trond Myklebust
2008-07-15 23:24 ` Andrew Morton
2008-07-15 23:44 ` Trond Myklebust [this message]
2008-07-16 19:58 ` Jason Baron
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=1216165492.7981.105.camel@localhost \
--to=trond.myklebust@fys.uio.no \
--cc=akpm@linux-foundation.org \
--cc=greg@kroah.com \
--cc=jbaron@redhat.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nick@nick-andrew.net \
--cc=randy.dunlap@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox