public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Baron <jbaron@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	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: Wed, 16 Jul 2008 15:58:18 -0400	[thread overview]
Message-ID: <20080716195818.GA6106@redhat.com> (raw)
In-Reply-To: <1216165492.7981.105.camel@localhost>

On Tue, Jul 15, 2008 at 07:44:52PM -0400, Trond Myklebust wrote:
> 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.
> 
> 

hi,

yes, i was aware of the breakage this patch introduced in the 
/proc/sys/sunrpc/* area...however, at his stage I was more interested in
feedback on the approach in the 'core' part of this patch. that is, the usage
of the hash table and bitmask to do module lookups. I didn't even feel this
was ready to be run by subsystem maintainers yet...but maybe it is...I will
try and 'cc the correct ppl going forward.

I like the above code suggestion for usage during a transition period. Perhaps,
all reads/writes to the /proc/sys/sunrpc/* files also emit a deprecation 
warning during the transition period.

I think the listing of the currently executing rpc calls, is so specific that
it continues to live on in /proc/sys/sunrpc/rpc_debug.

thanks,

-Jason


      reply	other threads:[~2008-07-16 20:00 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
2008-07-16 19:58             ` Jason Baron [this message]

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=20080716195818.GA6106@redhat.com \
    --to=jbaron@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nick@nick-andrew.net \
    --cc=randy.dunlap@oracle.com \
    --cc=trond.myklebust@fys.uio.no \
    /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