[ltt-dev] UST use case: Tracing QEMU/KVM

[Stefan Hajnoczi]

On Mon, May 24, 2010 at 4:57 AM, Pierre-Marc Fournier
<pierre-marc.fournier at polymtl.ca> wrote:

Thanks for the quick reply, Pierre-Marc.

> If there are specific subjects in mind you feel would benefit from being covered in more depth in the manual, please let me know.

For large programs or programs that closely manage resources, a
documented list of resources that libust uses would be useful.  This
information can be used to understand whether libust might interfere
with the program being traced.  For example, will heap allocations be
made after startup?  Will file descriptors be held open?  The listener
thread?

I don't understand the --create-trace, --alloc-trace, --destroy-trace,
and subbuf concepts that ustctl exposes.  Perhaps these are documented
in kernel LTTng and I haven't read that.

>> One note about the manual: the TP_PROTO() versus TPPROTO() change was
>> confusing.  Perhaps a note can be added to the manual that ust.git
>> uses TP_PROTO() but libust 0.4 uses TPPROTO()?
>
> This reflects an API change in the kernel. But you are right, this is confusing. I will do a 0.5 release next week, which will obsolete 0.4 and sync the manual.

Thanks.

>> poll([{fd=3, events=POLLIN}], 1, -1)      = ? ERESTART_RESTARTBLOCK (To
>> be restarted)
>> restart_syscall(<... resuming interrupted call ...>) = ?
>> ERESTART_RESTARTBLOCK (To be restarted)
>
> Hmmm. Do you have any pointers to documentation about this return code? I suspect userspace should never see it. Could it be a kernel bug?

I have sent an example that triggers this behavior and explains how it
can occur.

>> Finally, I had to add #undefs to get QEMU to build after including UST
>> headers.  Unfortunately the UST headers include headers that pollute
>> the (macro) namespace.
>>
>
> From examining the patch, I expect you are referring to mutex_lock and _unlock. I just did a commit to fix this.

Great, thanks.

Stefan