Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
Am 13.01.2021 um 15:15 hat Stefan Hajnoczi geschrieben: > On Wed, Jan 13, 2021 at 01:51:17PM +0100, BALATON Zoltan wrote: > > On Wed, 13 Jan 2021, Stefan Hajnoczi wrote: > > > On Tue, Jan 12, 2021 at 09:44:03PM +0100, BALATON Zoltan wrote: > > > > On Tue, 12 Jan 2021, Stefan Hajnoczi wrote: > > > > > It is possible to repeat the --trace option to specify multiple > > > > > patterns. This may be preferrable to users who do not want to create a > > > > > file with a list of patterns. > > > > > > > > > > Suggested-by: BALATON Zoltan > > > > > Signed-off-by: Stefan Hajnoczi > > > > > --- > > > > > docs/devel/tracing.rst | 9 +++-- > > > > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/docs/devel/tracing.rst b/docs/devel/tracing.rst > > > > > index 4ebf8e38ea..8777c19d14 100644 > > > > > --- a/docs/devel/tracing.rst > > > > > +++ b/docs/devel/tracing.rst > > > > > @@ -22,10 +22,15 @@ events:: > > > > > This output comes from the "log" trace backend that is enabled by > > > > > default when > > > > > ``./configure --enable-trace-backends=BACKENDS`` was not explicitly > > > > > specified. > > > > > > > > > > -More than one trace event pattern can be specified by providing a > > > > > file > > > > > -instead:: > > > > > +Multiple patterns can be specified by repeating the ``--trace`` > > > > > option:: > > > > > + > > > > > +$ qemu --trace "kvm_*" --trace "virtio_*" ... > > > > > > > > QEMU options are single dash with double dash accepted for > > > > compatibility but > > > > help and other docs have single dash so these (and below) should be > > > > -trace. > > > > (Also a bit less typing for otherwise already way too long command > > > > lines.) > > > > > > Is this documented somewhere? > > > > Maybe qemu-system-* -help ? > > I mean developer documentation like CODING_STYLE.rst so we can point to > that when someone submits a patch that does not use the preferred > syntax. > > > > I was under the impression that '-' is legacy syntax and '--' is the > > > preferred syntax. There are examples of '--' on the QEMU man page. > > > > -- is also accepted but they are the same as single dash options. Some tools > > may have -- syntax preferred but not QEMU itself. If so that may be an > > inconsistency. > > > > > Let's reach agreement, document it, and then make the documentation > > > consistent. > > > > Since we don't have long and short arguments for the same options (like > > -m,--memory) I think -- does not make much sense. Also single dash is less > > typing and there are other programs using the same convention (e.g. whole X > > Window System) so I think the current one dash options are fine and should > > be kept consistent. As long as we can agree on this I can agree with that. > > :-) > > I'm fine with either (or even using both interchangeably) but want to > make sure it's agreed for all of QEMU so we can really follow it and > don't need to spend time on it in the future. > > Kevin: You used '--' in qemu-storage-daemon --help. Does this mean you > want QEMU to stop using '-'? qemu-storage-daemon just follows the example of the other tools which use getopt() instead of a hand-written parser, which means that in all of the tools, long options require '--'. I don't have a strong opinion about '-' in the system emulator, though if I tried out dropping it, I guess I'd find my muscle memory does have one. Kevin signature.asc Description: PGP signature
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On Tue, Jan 19, 2021 at 10:31:49AM -0600, Eric Blake wrote: > On 1/14/21 8:18 AM, BALATON Zoltan wrote: > > >> I wasn't aware of the fact that some of the utilities are sensitive to > >> '--' vs '-'! I'm in favor of consistently using '--' in documentation > >> but allowing both for backwards compatibility where '-' is currently > >> supported. > >> > >> If we are in agreement, then let's: > >> > >> 1. Add a section to CODING_STYLE.rst or other developer documentation > >> documenting this. > > Seems reasonable to me. > > > > > I'd be more in favour of documenting that QEMU accepts - options but > > also -- as alternative and fixing the tools that currently use > > getopt_long to use getopt_long_only to keep it consistent with main QEMU > > executable. Otherwise this will get more and more inconsistent with new > > options added with -- and old ones only exist in - form so to keep > > consistency we should standardise on - not --. > > I've got less practical experience with getopt_long_only(); I know there > are some utilities like gcc that have to use it, but GNU coding > standards prefer getopt_long() over getopt_long_only(). I think one of > the reasons is the potential for ambiguity: if you have a program that > accepts a series of short options without arguments, you can combine > them together (think 'ls -lF'), but what happens when your combination > of letters then resembles a long option? A bit contrived, but 'ls --no' > is short for 'ls --no-group' (aka 'ls -G'), while 'ls -no' is the same > as 'ls -n -o', which has different behavior. ls uses getopt_long(), > hence the use of -- matters; but if it were to use getopt_long_only(), > you would have changed the behavior of 'ls -no' (it would now favor > --no-group over -n -o). > > That's not to say we can't switch qemu-img, qemu-storage-daemon, > qemu-io, and friends to use getopt_long_only(), but merely that we have > to be careful of what it will do to their command line parsing, and > whether it will introduce any unintended regressions. > > So the conservative answer from me is to prefer documenting '--' options > everywhere, rather than trying to figure out when '-' is acceptable with > long option names. > > > > >> 2. Convert existing documentation to use '--'. This will make it more > >> consistent and also avoid confusion about '-' vs '--'. > > > > You could still use -- in documentation but what's the problem with - if > > -- is also accepted if one wants to type that? > > Supporting lazy typists is one thing, but our documentation should stick > to the preferred form, even when shorter forms are possible. I lost track of this email thread. Do we have agreement on that QEMU documentation should consistently use '--' for long options? Stefan signature.asc Description: PGP signature
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On 1/14/21 8:18 AM, BALATON Zoltan wrote: >> I wasn't aware of the fact that some of the utilities are sensitive to >> '--' vs '-'! I'm in favor of consistently using '--' in documentation >> but allowing both for backwards compatibility where '-' is currently >> supported. >> >> If we are in agreement, then let's: >> >> 1. Add a section to CODING_STYLE.rst or other developer documentation >> documenting this. Seems reasonable to me. > > I'd be more in favour of documenting that QEMU accepts - options but > also -- as alternative and fixing the tools that currently use > getopt_long to use getopt_long_only to keep it consistent with main QEMU > executable. Otherwise this will get more and more inconsistent with new > options added with -- and old ones only exist in - form so to keep > consistency we should standardise on - not --. I've got less practical experience with getopt_long_only(); I know there are some utilities like gcc that have to use it, but GNU coding standards prefer getopt_long() over getopt_long_only(). I think one of the reasons is the potential for ambiguity: if you have a program that accepts a series of short options without arguments, you can combine them together (think 'ls -lF'), but what happens when your combination of letters then resembles a long option? A bit contrived, but 'ls --no' is short for 'ls --no-group' (aka 'ls -G'), while 'ls -no' is the same as 'ls -n -o', which has different behavior. ls uses getopt_long(), hence the use of -- matters; but if it were to use getopt_long_only(), you would have changed the behavior of 'ls -no' (it would now favor --no-group over -n -o). That's not to say we can't switch qemu-img, qemu-storage-daemon, qemu-io, and friends to use getopt_long_only(), but merely that we have to be careful of what it will do to their command line parsing, and whether it will introduce any unintended regressions. So the conservative answer from me is to prefer documenting '--' options everywhere, rather than trying to figure out when '-' is acceptable with long option names. > >> 2. Convert existing documentation to use '--'. This will make it more >> consistent and also avoid confusion about '-' vs '--'. > > You could still use -- in documentation but what's the problem with - if > -- is also accepted if one wants to type that? Supporting lazy typists is one thing, but our documentation should stick to the preferred form, even when shorter forms are possible. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On 1/14/21 9:02 AM, Stefan Hajnoczi wrote: 1. Add a section to CODING_STYLE.rst or other developer documentation documenting this. 2. Convert existing documentation to use '--'. This will make it more consistent and also avoid confusion about '-' vs '--'. John: Do you have time to do these things as part of your QEMU command-line and API improvement work? I will add it to my todoist task list, but I am still neck deep in the QAPI forest, so it won't be a priority in the short term. --js
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On Thu, Jan 14, 2021 at 03:18:48PM +0100, BALATON Zoltan wrote: > On Thu, 14 Jan 2021, Stefan Hajnoczi wrote: > > On Wed, Jan 13, 2021 at 07:20:42PM -0500, John Snow wrote: > > > On 1/13/21 6:45 PM, BALATON Zoltan wrote: > > > > > > > > Please don't. That would break all scripts that already call qemu using > > > > single dash options. Forcing everyone to edit their scripts is not nice. > > > > How about also accepting single dash in qemu-img for consistency then > > > > you can use whatever you want in docs as long as single dash still works > > > > for consistency and backward compatibility. > > > > > > That's not what I meant -- I meant for documentation purposes. QEMU can > > > keep > > > accepting single dash, but we should standardize on the spelling for > > > purposes of interactive messages, documentation, etc. > > > > I wasn't aware of the fact that some of the utilities are sensitive to > > '--' vs '-'! I'm in favor of consistently using '--' in documentation > > but allowing both for backwards compatibility where '-' is currently > > supported. > > > > If we are in agreement, then let's: > > > > 1. Add a section to CODING_STYLE.rst or other developer documentation > > documenting this. > > I'd be more in favour of documenting that QEMU accepts - options but also -- > as alternative and fixing the tools that currently use getopt_long to use > getopt_long_only to keep it consistent with main QEMU executable. Otherwise > this will get more and more inconsistent with new options added with -- and > old ones only exist in - form so to keep consistency we should standardise > on - not --. > > > 2. Convert existing documentation to use '--'. This will make it more > > consistent and also avoid confusion about '-' vs '--'. > > You could still use -- in documentation but what's the problem with - if -- > is also accepted if one wants to type that? What is the policy for QEMU documentation? 1. Use '-' everywhere or 2. Use '--' everywhere or 3. Use whichever you prefer or ? Stefan signature.asc Description: PGP signature
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On Thu, 14 Jan 2021, Stefan Hajnoczi wrote: On Wed, Jan 13, 2021 at 07:20:42PM -0500, John Snow wrote: On 1/13/21 6:45 PM, BALATON Zoltan wrote: Please don't. That would break all scripts that already call qemu using single dash options. Forcing everyone to edit their scripts is not nice. How about also accepting single dash in qemu-img for consistency then you can use whatever you want in docs as long as single dash still works for consistency and backward compatibility. That's not what I meant -- I meant for documentation purposes. QEMU can keep accepting single dash, but we should standardize on the spelling for purposes of interactive messages, documentation, etc. I wasn't aware of the fact that some of the utilities are sensitive to '--' vs '-'! I'm in favor of consistently using '--' in documentation but allowing both for backwards compatibility where '-' is currently supported. If we are in agreement, then let's: 1. Add a section to CODING_STYLE.rst or other developer documentation documenting this. I'd be more in favour of documenting that QEMU accepts - options but also -- as alternative and fixing the tools that currently use getopt_long to use getopt_long_only to keep it consistent with main QEMU executable. Otherwise this will get more and more inconsistent with new options added with -- and old ones only exist in - form so to keep consistency we should standardise on - not --. 2. Convert existing documentation to use '--'. This will make it more consistent and also avoid confusion about '-' vs '--'. You could still use -- in documentation but what's the problem with - if -- is also accepted if one wants to type that? Regards, BALATON Zoltan
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On Wed, Jan 13, 2021 at 07:20:42PM -0500, John Snow wrote: > On 1/13/21 6:45 PM, BALATON Zoltan wrote: > > > > Please don't. That would break all scripts that already call qemu using > > single dash options. Forcing everyone to edit their scripts is not nice. > > How about also accepting single dash in qemu-img for consistency then > > you can use whatever you want in docs as long as single dash still works > > for consistency and backward compatibility. > > That's not what I meant -- I meant for documentation purposes. QEMU can keep > accepting single dash, but we should standardize on the spelling for > purposes of interactive messages, documentation, etc. I wasn't aware of the fact that some of the utilities are sensitive to '--' vs '-'! I'm in favor of consistently using '--' in documentation but allowing both for backwards compatibility where '-' is currently supported. If we are in agreement, then let's: 1. Add a section to CODING_STYLE.rst or other developer documentation documenting this. 2. Convert existing documentation to use '--'. This will make it more consistent and also avoid confusion about '-' vs '--'. John: Do you have time to do these things as part of your QEMU command-line and API improvement work? Thanks, Stefan signature.asc Description: PGP signature
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On 1/13/21 6:45 PM, BALATON Zoltan wrote: Please don't. That would break all scripts that already call qemu using single dash options. Forcing everyone to edit their scripts is not nice. How about also accepting single dash in qemu-img for consistency then you can use whatever you want in docs as long as single dash still works for consistency and backward compatibility. That's not what I meant -- I meant for documentation purposes. QEMU can keep accepting single dash, but we should standardize on the spelling for purposes of interactive messages, documentation, etc. --js
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On Wed, 13 Jan 2021, John Snow wrote: On 1/13/21 5:15 PM, Eric Blake wrote: On 1/13/21 3:42 PM, John Snow wrote: On 1/13/21 4:48 AM, Stefan Hajnoczi wrote: QEMU options are single dash with double dash accepted for compatibility but help and other docs have single dash so these (and below) should be -trace. (Also a bit less typing for otherwise already way too long command lines.) Is this documented somewhere? I was under the impression that '-' is legacy syntax and '--' is the preferred syntax. There are examples of '--' on the QEMU man page. Historically, uses of 'getopt_long()' support only double dash, while 'getopt_long_only()' support both single and double. While qemu does not use getopt_long_only() (because it rolls its own parser instead), it certainly tries to behave as if it does. Meanwhile, our other tools like qemu-img or qemu-storage-daemon use getopt_long(). I'm in favor of preferring the double-dash in documentation, even when single-dash works, especially for any option (like --trace) that is used for more tools than just qemu proper, because it makes for easier copy-paste between options that work for all tools in the qemu suite rather than just qemu. Yes, this makes sense. Let's reach agreement, document it, and then make the documentation consistent. Stefan My naive impression was that double-dash is the preferred idiom in linuxdom in general for any multi-character option. We might hang on to single-dash for backwards compatibility, but I doubt we want to enshrine that as our preferred way. Is there a reasoning I am unaware of? Continuing to document '-machine' instead of '--machine' for qemu is debatable because we don't support 'qemu-img --machine' or 'qemu-storage-daemon --machine'; but since 'qemu-img -trace' is an error while 'qemu-img --trace' works, I'm definitely in favor of preferring '--trace' everywhere in our docs. At that point, it's a guessing game as to which binaries support which flags and using which spellings -- maybe some will pick up new flags later and so on. Skip the fuss and just insist on the double dash, I think. Please don't. That would break all scripts that already call qemu using single dash options. Forcing everyone to edit their scripts is not nice. How about also accepting single dash in qemu-img for consistency then you can use whatever you want in docs as long as single dash still works for consistency and backward compatibility. Regards, BALATON Zoltan
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On 1/13/21 5:15 PM, Eric Blake wrote: On 1/13/21 3:42 PM, John Snow wrote: On 1/13/21 4:48 AM, Stefan Hajnoczi wrote: QEMU options are single dash with double dash accepted for compatibility but help and other docs have single dash so these (and below) should be -trace. (Also a bit less typing for otherwise already way too long command lines.) Is this documented somewhere? I was under the impression that '-' is legacy syntax and '--' is the preferred syntax. There are examples of '--' on the QEMU man page. Historically, uses of 'getopt_long()' support only double dash, while 'getopt_long_only()' support both single and double. While qemu does not use getopt_long_only() (because it rolls its own parser instead), it certainly tries to behave as if it does. Meanwhile, our other tools like qemu-img or qemu-storage-daemon use getopt_long(). I'm in favor of preferring the double-dash in documentation, even when single-dash works, especially for any option (like --trace) that is used for more tools than just qemu proper, because it makes for easier copy-paste between options that work for all tools in the qemu suite rather than just qemu. Yes, this makes sense. Let's reach agreement, document it, and then make the documentation consistent. Stefan My naive impression was that double-dash is the preferred idiom in linuxdom in general for any multi-character option. We might hang on to single-dash for backwards compatibility, but I doubt we want to enshrine that as our preferred way. Is there a reasoning I am unaware of? Continuing to document '-machine' instead of '--machine' for qemu is debatable because we don't support 'qemu-img --machine' or 'qemu-storage-daemon --machine'; but since 'qemu-img -trace' is an error while 'qemu-img --trace' works, I'm definitely in favor of preferring '--trace' everywhere in our docs. At that point, it's a guessing game as to which binaries support which flags and using which spellings -- maybe some will pick up new flags later and so on. Skip the fuss and just insist on the double dash, I think. --js
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On 1/13/21 3:42 PM, John Snow wrote: > On 1/13/21 4:48 AM, Stefan Hajnoczi wrote: >>> QEMU options are single dash with double dash accepted for >>> compatibility but >>> help and other docs have single dash so these (and below) should be >>> -trace. >>> (Also a bit less typing for otherwise already way too long command >>> lines.) >> Is this documented somewhere? >> >> I was under the impression that '-' is legacy syntax and '--' is the >> preferred syntax. There are examples of '--' on the QEMU man page. Historically, uses of 'getopt_long()' support only double dash, while 'getopt_long_only()' support both single and double. While qemu does not use getopt_long_only() (because it rolls its own parser instead), it certainly tries to behave as if it does. Meanwhile, our other tools like qemu-img or qemu-storage-daemon use getopt_long(). I'm in favor of preferring the double-dash in documentation, even when single-dash works, especially for any option (like --trace) that is used for more tools than just qemu proper, because it makes for easier copy-paste between options that work for all tools in the qemu suite rather than just qemu. >> >> Let's reach agreement, document it, and then make the documentation >> consistent. >> >> Stefan > > My naive impression was that double-dash is the preferred idiom in > linuxdom in general for any multi-character option. > > We might hang on to single-dash for backwards compatibility, but I doubt > we want to enshrine that as our preferred way. > > Is there a reasoning I am unaware of? Continuing to document '-machine' instead of '--machine' for qemu is debatable because we don't support 'qemu-img --machine' or 'qemu-storage-daemon --machine'; but since 'qemu-img -trace' is an error while 'qemu-img --trace' works, I'm definitely in favor of preferring '--trace' everywhere in our docs. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On 1/13/21 4:48 AM, Stefan Hajnoczi wrote: QEMU options are single dash with double dash accepted for compatibility but help and other docs have single dash so these (and below) should be -trace. (Also a bit less typing for otherwise already way too long command lines.) Is this documented somewhere? I was under the impression that '-' is legacy syntax and '--' is the preferred syntax. There are examples of '--' on the QEMU man page. Let's reach agreement, document it, and then make the documentation consistent. Stefan My naive impression was that double-dash is the preferred idiom in linuxdom in general for any multi-character option. We might hang on to single-dash for backwards compatibility, but I doubt we want to enshrine that as our preferred way. Is there a reasoning I am unaware of?
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On Wed, Jan 13, 2021 at 01:51:17PM +0100, BALATON Zoltan wrote: > On Wed, 13 Jan 2021, Stefan Hajnoczi wrote: > > On Tue, Jan 12, 2021 at 09:44:03PM +0100, BALATON Zoltan wrote: > > > On Tue, 12 Jan 2021, Stefan Hajnoczi wrote: > > > > It is possible to repeat the --trace option to specify multiple > > > > patterns. This may be preferrable to users who do not want to create a > > > > file with a list of patterns. > > > > > > > > Suggested-by: BALATON Zoltan > > > > Signed-off-by: Stefan Hajnoczi > > > > --- > > > > docs/devel/tracing.rst | 9 +++-- > > > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/docs/devel/tracing.rst b/docs/devel/tracing.rst > > > > index 4ebf8e38ea..8777c19d14 100644 > > > > --- a/docs/devel/tracing.rst > > > > +++ b/docs/devel/tracing.rst > > > > @@ -22,10 +22,15 @@ events:: > > > > This output comes from the "log" trace backend that is enabled by > > > > default when > > > > ``./configure --enable-trace-backends=BACKENDS`` was not explicitly > > > > specified. > > > > > > > > -More than one trace event pattern can be specified by providing a file > > > > -instead:: > > > > +Multiple patterns can be specified by repeating the ``--trace`` > > > > option:: > > > > + > > > > +$ qemu --trace "kvm_*" --trace "virtio_*" ... > > > > > > QEMU options are single dash with double dash accepted for compatibility > > > but > > > help and other docs have single dash so these (and below) should be > > > -trace. > > > (Also a bit less typing for otherwise already way too long command lines.) > > > > Is this documented somewhere? > > Maybe qemu-system-* -help ? I mean developer documentation like CODING_STYLE.rst so we can point to that when someone submits a patch that does not use the preferred syntax. > > I was under the impression that '-' is legacy syntax and '--' is the > > preferred syntax. There are examples of '--' on the QEMU man page. > > -- is also accepted but they are the same as single dash options. Some tools > may have -- syntax preferred but not QEMU itself. If so that may be an > inconsistency. > > > Let's reach agreement, document it, and then make the documentation > > consistent. > > Since we don't have long and short arguments for the same options (like > -m,--memory) I think -- does not make much sense. Also single dash is less > typing and there are other programs using the same convention (e.g. whole X > Window System) so I think the current one dash options are fine and should > be kept consistent. As long as we can agree on this I can agree with that. > :-) I'm fine with either (or even using both interchangeably) but want to make sure it's agreed for all of QEMU so we can really follow it and don't need to spend time on it in the future. Kevin: You used '--' in qemu-storage-daemon --help. Does this mean you want QEMU to stop using '-'? Stefan signature.asc Description: PGP signature
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On Tue, Jan 12, 2021 at 09:44:03PM +0100, BALATON Zoltan wrote: > On Tue, 12 Jan 2021, Stefan Hajnoczi wrote: > > It is possible to repeat the --trace option to specify multiple > > patterns. This may be preferrable to users who do not want to create a > > file with a list of patterns. > > > > Suggested-by: BALATON Zoltan > > Signed-off-by: Stefan Hajnoczi > > --- > > docs/devel/tracing.rst | 9 +++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/docs/devel/tracing.rst b/docs/devel/tracing.rst > > index 4ebf8e38ea..8777c19d14 100644 > > --- a/docs/devel/tracing.rst > > +++ b/docs/devel/tracing.rst > > @@ -22,10 +22,15 @@ events:: > > This output comes from the "log" trace backend that is enabled by default > > when > > ``./configure --enable-trace-backends=BACKENDS`` was not explicitly > > specified. > > > > -More than one trace event pattern can be specified by providing a file > > -instead:: > > +Multiple patterns can be specified by repeating the ``--trace`` option:: > > + > > +$ qemu --trace "kvm_*" --trace "virtio_*" ... > > QEMU options are single dash with double dash accepted for compatibility but > help and other docs have single dash so these (and below) should be -trace. > (Also a bit less typing for otherwise already way too long command lines.) Is this documented somewhere? I was under the impression that '-' is legacy syntax and '--' is the preferred syntax. There are examples of '--' on the QEMU man page. Let's reach agreement, document it, and then make the documentation consistent. Stefan signature.asc Description: PGP signature
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On Tue, 12 Jan 2021, Stefan Hajnoczi wrote: It is possible to repeat the --trace option to specify multiple patterns. This may be preferrable to users who do not want to create a file with a list of patterns. Suggested-by: BALATON Zoltan Signed-off-by: Stefan Hajnoczi --- docs/devel/tracing.rst | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/docs/devel/tracing.rst b/docs/devel/tracing.rst index 4ebf8e38ea..8777c19d14 100644 --- a/docs/devel/tracing.rst +++ b/docs/devel/tracing.rst @@ -22,10 +22,15 @@ events:: This output comes from the "log" trace backend that is enabled by default when ``./configure --enable-trace-backends=BACKENDS`` was not explicitly specified. -More than one trace event pattern can be specified by providing a file -instead:: +Multiple patterns can be specified by repeating the ``--trace`` option:: + +$ qemu --trace "kvm_*" --trace "virtio_*" ... QEMU options are single dash with double dash accepted for compatibility but help and other docs have single dash so these (and below) should be -trace. (Also a bit less typing for otherwise already way too long command lines.) Regards, BALATON Zoltan + +When patterns are used frequently it is more convenient to store them in a +file to avoid long command-line options:: $ echo "memory_region_ops_*" >/tmp/events +$ echo "kvm_*" >>/tmp/events $ qemu --trace events=/tmp/events ... Trace events -- 2.29.2
Re: [PATCH 1/2] trace: document how to specify multiple --trace patterns
On 1/12/21 5:58 PM, Stefan Hajnoczi wrote: > It is possible to repeat the --trace option to specify multiple > patterns. This may be preferrable to users who do not want to create a > file with a list of patterns. > > Suggested-by: BALATON Zoltan > Signed-off-by: Stefan Hajnoczi > --- > docs/devel/tracing.rst | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/docs/devel/tracing.rst b/docs/devel/tracing.rst > index 4ebf8e38ea..8777c19d14 100644 > --- a/docs/devel/tracing.rst > +++ b/docs/devel/tracing.rst > @@ -22,10 +22,15 @@ events:: > This output comes from the "log" trace backend that is enabled by default > when > ``./configure --enable-trace-backends=BACKENDS`` was not explicitly > specified. > > -More than one trace event pattern can be specified by providing a file > -instead:: > +Multiple patterns can be specified by repeating the ``--trace`` option:: > + > +$ qemu --trace "kvm_*" --trace "virtio_*" ... Yet another possible improvement is to describe the deselect pattern: --trace "virtio_*" --trace "-virtio_mem*" > + > +When patterns are used frequently it is more convenient to store them in a > +file to avoid long command-line options:: > > $ echo "memory_region_ops_*" >/tmp/events > +$ echo "kvm_*" >>/tmp/events Ditto: $ echo "-kvm_irqchip_*" >> /tmp/events > $ qemu --trace events=/tmp/events ... > > Trace events > Probably better in a different patch, so for this one: Reviewed-by: Philippe Mathieu-Daudé
[PATCH 1/2] trace: document how to specify multiple --trace patterns
It is possible to repeat the --trace option to specify multiple patterns. This may be preferrable to users who do not want to create a file with a list of patterns. Suggested-by: BALATON Zoltan Signed-off-by: Stefan Hajnoczi --- docs/devel/tracing.rst | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/docs/devel/tracing.rst b/docs/devel/tracing.rst index 4ebf8e38ea..8777c19d14 100644 --- a/docs/devel/tracing.rst +++ b/docs/devel/tracing.rst @@ -22,10 +22,15 @@ events:: This output comes from the "log" trace backend that is enabled by default when ``./configure --enable-trace-backends=BACKENDS`` was not explicitly specified. -More than one trace event pattern can be specified by providing a file -instead:: +Multiple patterns can be specified by repeating the ``--trace`` option:: + +$ qemu --trace "kvm_*" --trace "virtio_*" ... + +When patterns are used frequently it is more convenient to store them in a +file to avoid long command-line options:: $ echo "memory_region_ops_*" >/tmp/events +$ echo "kvm_*" >>/tmp/events $ qemu --trace events=/tmp/events ... Trace events -- 2.29.2
