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: Wed, 27 Sep 2006 09:55:10 +0200 [thread overview]
Message-ID: <200609270955.10894.philipp.reisner@linbit.com> (raw)
In-Reply-To: <342BAC0A5467384983B586A6B0B37671039D4C4D@EXNA.corp.stratus.com>
Am Dienstag, 26. September 2006 23:42 schrieb Graham, Simon:
> Hi Philipp,
>
> Just want to make sure I understand fully...
>
> > 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)
>
> I was not aware of DTrace but I have looked at SystemTap and decided it
> doesn't really work -- we need some level of trace that is always turned
> on (so we can diagnose field problems after the fact) combined with the
> ability to enable more extensive tracing at will and I don't think
> SystemTap will do both of these. To be honest I don't really like the
> fact that the tracing definition is separate from the driver code
> (probably the exact reason why other people like it
> ;-)
>
> Also -- whilst there may be work afoot to add this to the kernel, we
> need this now with the current kernel versions we are going to ship
> product with - I know that printk's are perhaps not the best (especially
> if you aren't careful about where to insert them) but they do provide
> what is needed now.
Right.
> > So, over all, I will accept a patch:
> > * That converts our current stuff over to such a tracing framework
>
> Do you mean you want all the existing INFO/WARN/etc tracing to use this?
>
Hi Simon,
No, sorry. I did not express myself clearly.
I am happy with your approach:
1) Having the framework in place first
2) Converting the current INFO/WARN statements over to it next
3) Adding more stuff to it later
I think the only thing that was missing from your patch
was the ability to disable it completely it compile time.
If you had not sent it with the comment 'FOR REVIEW' I had probably
comited it to SVN. ;)
-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 :
next prev parent reply other threads:[~2006-09-27 7:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-26 21:42 [Drbd-dev] DRBD-8: <FOR REVIEW> dynamic tracing facility Graham, Simon
2006-09-27 7:55 ` Philipp Reisner [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-09-27 12:29 Graham, Simon
2006-09-24 13:47 Graham, Simon
2006-09-26 16:23 ` Philipp Reisner
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=200609270955.10894.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