qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/2] add some virtio-scsi trace events
Date: Thu, 29 Aug 2013 17:35:24 +0200	[thread overview]
Message-ID: <521F6A3C.5060702@redhat.com> (raw)
In-Reply-To: <521F607F.70001@redhat.com>

On 08/29/13 16:53, Paolo Bonzini wrote:

>> (c) The way I submitted the series, the events in question are disabled
>> in "trace-events". Check out the functions themselves: they are
>> protected (ie. even the trace_event_get_state() calls are protected)
>> with preprocessing directives. I did it this way because I call them in
>> several places, and I wanted to keep the #if's centralized.
> 
> Tracing was supposed to remove the need for #if... :)

Tracing was supposed not to be broken under dtrace either I presume?

> I'll try to salvage the patch.

I won't bother next time. I wouldn't want you to waste your time on
"salvaging" the clearly broken patches that I submit.

To be clear, I considered this series a favor. I don't need it to be
accepted. It's easier for me to write ad-hoc debug printf()s each time.
They don't depend on anything, they can print just the right set of info
that I need, and they work in any component imaginable.

In comparison, the bikeshedding you repeatedly indulge in is unbearable.
You keep splitting hairs and rejecting patches just because they are not
in your taste; you don't need any other reason.

NB I haven't just thrown this over the wall. I spent most of today on
this series and tried to cover all my bases, perusing the documentation,
testing the series, making an honest effort. The one thing that I
*can't* prepare for is your adoration of your own taste.

If you attribute such paramount importance to your taste, perhaps next
time write the crap yourself that you tend to ask me for.

Of course there are times when I can't just ignore you and walk away.
Maybe I'll look for different responsibilities if that becomes the norm.

Laszlo

  reply	other threads:[~2013-08-29 15:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-29 13:36 [Qemu-devel] [PATCH 0/2] some virtio-scsi tracing Laszlo Ersek
2013-08-29 13:37 ` [Qemu-devel] [PATCH 1/2] qemu_hexstr(): hexdump a small buffer to a string, for in-line printing Laszlo Ersek
2013-08-29 16:32   ` Markus Armbruster
2013-08-29 13:37 ` [Qemu-devel] [PATCH 2/2] add some virtio-scsi trace events Laszlo Ersek
2013-08-29 13:59   ` Paolo Bonzini
2013-08-29 14:18     ` Laszlo Ersek
2013-08-29 14:53       ` Paolo Bonzini
2013-08-29 15:35         ` Laszlo Ersek [this message]
2013-08-29 15:42           ` Paolo Bonzini
2013-09-04 14:21   ` Stefan Hajnoczi
2013-09-05  1:26     ` Laszlo Ersek

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=521F6A3C.5060702@redhat.com \
    --to=lersek@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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;
as well as URLs for NNTP newsgroup(s).