Re: [Qemu-devel] [PATCH 2/2] add tracing of scsi requests

[Stefan Hajnoczi <stefanha@gmail.com>]

On Fri, Apr 15, 2011 at 3:22 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 04/15/2011 04:15 PM, Stefan Hajnoczi wrote:
>>
>> On Fri, Apr 15, 2011 at 2:24 PM, Paolo Bonzini<pbonzini@redhat.com>
>>  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