[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/2] add tracing of scsi requests
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH 2/2] add tracing of scsi requests |
Date: |
Fri, 15 Apr 2011 15:32:15 +0100 |
On Fri, Apr 15, 2011 at 3:22 PM, Paolo Bonzini <address@hidden> wrote:
> On 04/15/2011 04:15 PM, Stefan Hajnoczi wrote:
>>
>> On Fri, Apr 15, 2011 at 2:24 PM, Paolo Bonzini<address@hidden>
>> wrote:
>>>
>>> +disable scsi_req_parsed(int target, int lun, int tag, int cmd, const
>>> char *cmdname, int mode, int xfer, uint64_t lba) "target %d lun %d tag %d
>>> command %d (%s) dir %d length %d lba %"PRIu64""
>>
>> Tracing strings isn't possible with all trace backends, so we should
>> avoid it. It works fine with stderr but other trace backends may not
>> be in the same address space (they are unable to dereference pointers
>> to strings) or simply not have the ability to record variable-length
>> data.
>
> Yeah, I saw them. What happens with the other backends? Do they crash or
> do they just record bogus data? If the latter (like IIRC simpletrace), I'd
> really like to keep the string. It is duplicating the cmd argument, so it
> is possible to work without it on non-stderr backends; with stderr OTOH the
> human-readable version is really useful before you have learnt the SCSI spec
> by heart. :)
There should be no crashes during tracing but if a pretty-printing
tool uses the format string then there will be a crash :). Right now
only stderr and ust use the format string. I've forgotten whether or
not ust is happy with %s.
Once we allow %s how long will it take until people use it without
including the raw data?
Basically, yes, you can get away with it in some cases but it's a
slippery slope. I'd rather forbid it now than end up with a confusing
or half-working mess later.
Stefan