From mboxrd@z Thu Jan 1 00:00:00 1970 From: stefanha@gmail.com (Stefan Hajnoczi) Date: Mon, 24 May 2010 10:00:59 +0100 Subject: [ltt-dev] UST use case: Tracing QEMU/KVM In-Reply-To: <1274673453.6759.5.camel@Nokia-N900-42-11> References: <1274673453.6759.5.camel@Nokia-N900-42-11> Message-ID: On Mon, May 24, 2010 at 4:57 AM, Pierre-Marc Fournier 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