Distributed Replicated Block Device (DRBD) development
 help / color / mirror / Atom feed
From: Philipp Reisner <philipp.reisner@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] DRBD-8: <FOR REVIEW> dynamic tracing facility
Date: Tue, 26 Sep 2006 18:23:54 +0200	[thread overview]
Message-ID: <200609261823.54543.philipp.reisner@linbit.com> (raw)
In-Reply-To: <342BAC0A5467384983B586A6B0B37671039D46DF@EXNA.corp.stratus.com>

Am Sonntag, 24. September 2006 15:47 schrieb Graham, Simon:
> As we discussed a few weeks ago, I propose adding a more general purpose
> trace facility that can be controlled at run time - attached is a patch
> that implements the following:
>
> . New macros TRACE/MTRACE that can be used to add trace statements
> (using existing macros/routines) that
>   are controlled at run time.
> . Controls are module parameters:
>   . trace_type - bitmap of enabled types; currently defined are
> packet-dump, bio-dump, uuid-dump
>   . trace_level - the higher the level, the more detail
>   . trace_devs - bitmap of devices for which trace is enabled
> . I've converted the packet dumping code to use this
> . I've added two new types using it:
>   . bio-dump - this dumps info on bio's coming from above drbd. This is
> controlled by a new config
>     parameter DUMP_EACH_BIO that is off by default (although I think it
> could be on by default and
>     will be in our version).
>   . uuid-dump - dumps info on updates to uuid's, comparisons, etc
>
> I actually went back and forth on how much of this to implement inline
> versus via a routine call and it turned out to be pretty much the same
> amount of code at each trace site no matter what so I made it all
> inline.
>
> Comments?

Hi Simon,

I have two opinions about this:
 * Good stuff, it is nice to have all this in place, although I would 
   also like to disable the whole tracing/dumping at compile time.

 * On the other hand I am not sure if it could become obsolete by
   the current rumours about a DTrace replacement on Linux (SystemTrap)

So, over all, I will accept a patch:
 * That converts our current stuff over to such a tracing framework
 * Probably add event more tracing. (As you have done for UUIDs)
 * The tracing facility allowes to enable/disable different classes
   of tracing information at run-time.
 * But I would also like to disable it at completely at compile time.

-Phil
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :

  reply	other threads:[~2006-09-26 16:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-24 13:47 [Drbd-dev] DRBD-8: <FOR REVIEW> dynamic tracing facility Graham, Simon
2006-09-26 16:23 ` Philipp Reisner [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-09-26 21:42 Graham, Simon
2006-09-27  7:55 ` Philipp Reisner
2006-09-27 12:29 Graham, Simon

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=200609261823.54543.philipp.reisner@linbit.com \
    --to=philipp.reisner@linbit.com \
    --cc=drbd-dev@lists.linbit.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