qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/4] trace: enable trace events in qemu-img


From: Denis V. Lunev
Subject: Re: [Qemu-devel] [PATCH 4/4] trace: enable trace events in qemu-img
Date: Tue, 31 May 2016 15:55:23 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 05/31/2016 03:50 PM, Eric Blake wrote:
On 05/31/2016 04:07 AM, Denis V. Lunev wrote:
The command will work this way:
     qemu-img create --trace qcow2* -f qcow2 1.img 64G

Signed-off-by: Denis V. Lunev <address@hidden>
Suggested by: Daniel P. Berrange <address@hidden>
CC: Eric Blake <address@hidden>
CC: Paolo Bonzini <address@hidden>
CC: Stefan Hajnoczi <address@hidden>
CC: Kevin Wolf <address@hidden>
---
  qemu-img.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
  1 file changed, 96 insertions(+), 1 deletion(-)
Missing man page additions.


@@ -155,7 +157,12 @@ static void QEMU_NORETURN help(void)
             "Parameters to compare subcommand:\n"
             "  '-f' first image format\n"
             "  '-F' second image format\n"
-           "  '-s' run in Strict mode - fail on different image size or sector 
allocation\n";
+           "  '-s' run in Strict mode - fail on different image size or sector 
allocation\n"
+           "\n"
+           "General purpose options:\n"
+           "  -R, --trace [[enable=]<pattern>][,events=<file>][,file=<file>]\n"
+           "       specify tracing options\n"
+           "       see qemu(1) man page for full description\n";
Why -R? Because -T is already in use by rebase and compare?  I'd almost
rather have _just_ --trace with no short option, than to pick yet
another letter, but you might want to wait for other opinions first.

I'd list general parameters before sub-command parameters.  I'd also
update the synopsis:

qemu-img [general options] command [command options]

Actually me too. I have though about this before submission but stick to
current approach following Fam's locking games. This would make the code MUCH better.

Fam, may be this also makes sense for your games with locking...

Den



reply via email to

[Prev in Thread] Current Thread [Next in Thread]