From: Markus Armbruster <armbru@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
qemu-devel@nongnu.org,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Christian Schoenebeck" <qemu_oss@crudebyte.com>,
"Michael Roth" <michael.roth@amd.com>,
"Eric Blake" <eblake@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Greg Kurz" <groug@kaod.org>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Kyle Evans" <kevans@freebsd.org>, "Warner Losh" <imp@bsdimp.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Riku Voipio" <riku.voipio@iki.fi>
Subject: Re: [PATCH v3 05/10] qapi: make the vcpu parameters deprecated for 8.1
Date: Sat, 06 May 2023 09:20:46 +0200 [thread overview]
Message-ID: <87a5yirkmp.fsf@pond.sub.org> (raw)
In-Reply-To: <20230505155336.137393-6-alex.bennee@linaro.org> ("Alex Bennée"'s message of "Fri, 5 May 2023 16:53:31 +0100")
Alex Bennée <alex.bennee@linaro.org> writes:
> I don't think I can remove the parameters directly but certainly mark
> them as deprecated.
>
> Message-Id: <20230420150009.1675181-6-alex.bennee@linaro.org>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Message-Id: <20230503091756.1453057-6-alex.bennee@linaro.org>
> ---
> qapi/trace.json | 22 +++++++---------------
> 1 file changed, 7 insertions(+), 15 deletions(-)
>
> diff --git a/qapi/trace.json b/qapi/trace.json
> index f425d10764..de6b1681aa 100644
> --- a/qapi/trace.json
> +++ b/qapi/trace.json
> @@ -33,9 +33,9 @@
> #
> # @name: Event name.
> # @state: Tracing state.
> -# @vcpu: Whether this is a per-vCPU event (since 2.7).
> +# @vcpu: Whether this is a per-vCPU event (deprecated since 8.1).
We don't normally replace the (since ...) when we deprecate.
> #
> -# An event is per-vCPU if it has the "vcpu" property in the "trace-events"
> +# There are no longer any events with the "vcpu" property in the "trace-events"
Why would a user still need to know what @vcpu used to mean? Also, long
line. See below for a possible alternative.
> # files.
> #
> # Since: 2.2
You need to make it official, like so:
{ 'struct': 'TraceEventInfo',
- 'data': {'name': 'str', 'state': 'TraceEventState', 'vcpu': 'bool'} }
+ 'data': {'name': 'str', 'state': 'TraceEventState',
+ 'vcpu': { 'type': 'bool', 'features': ['deprecated'] } } }
And then the generator will demand you document it formally, so you also
need something like
# @state: Tracing state.
# @vcpu: Whether this is a per-vCPU event (since 2.7).
#
-# An event is per-vCPU if it has the "vcpu" property in the "trace-events"
-# files.
+# Features:
+# @deprecated: Member @vcpu is deprecated, and always false.
#
# Since: 2.2
##
Additionally, update docs/about/deprecated.rst.
> @@ -49,19 +49,15 @@
> # Query the state of events.
> #
> # @name: Event name pattern (case-sensitive glob).
> -# @vcpu: The vCPU to query (any by default; since 2.7).
> +# @vcpu: The vCPU to query (deprecated since 8.1).
Again, we don't normally replace the (since ...) when we deprecate.
I suggest to just drop the "any by default" part.
> #
> # Returns: a list of @TraceEventInfo for the matching events
> #
> # An event is returned if:
> #
> # - its name matches the @name pattern, and
> -# - if @vcpu is given, the event has the "vcpu" property.
> #
> -# Therefore, if @vcpu is given, the operation will only match per-vCPU events,
> -# returning their state on the specified vCPU. Special case: if @name is an
> -# exact match, @vcpu is given and the event does not have the "vcpu" property,
> -# an error is returned.
> +# There are no longer any per-vCPU events
> #
> # Since: 2.2
> #
Please add 'features': ['deprecated'].
> @@ -84,17 +80,13 @@
> # @name: Event name pattern (case-sensitive glob).
> # @enable: Whether to enable tracing.
> # @ignore-unavailable: Do not match unavailable events with @name.
> -# @vcpu: The vCPU to act upon (all by default; since 2.7).
> +# @vcpu: The vCPU to act upon (deprecated since 8.1).
Suggest to just drop the "all by default" part.
> #
> # An event's state is modified if:
> #
> -# - its name matches the @name pattern, and
> -# - if @vcpu is given, the event has the "vcpu" property.
> +# - its name matches the @name pattern
> #
> -# Therefore, if @vcpu is given, the operation will only match per-vCPU events,
> -# setting their state on the specified vCPU. Special case: if @name is an exact
> -# match, @vcpu is given and the event does not have the "vcpu" property, an
> -# error is returned.
> +# There are no longer and per-vCPU events so specifying it will never match.
> #
> # Since: 2.2
> #
Please add 'features': ['deprecated'].
next prev parent reply other threads:[~2023-05-06 7:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-05 15:53 [PATCH v3 00/10] tracing: remove dynamic vcpu state Alex Bennée
2023-05-05 15:53 ` [PATCH v3 01/10] *-user: remove the guest_user_syscall tracepoints Alex Bennée
2023-05-05 15:53 ` [PATCH v3 02/10] trace-events: remove the remaining vcpu trace events Alex Bennée
2023-05-05 15:53 ` [PATCH v3 03/10] trace: remove vcpu_id from the TraceEvent structure Alex Bennée
2023-05-05 15:53 ` [PATCH v3 04/10] scripts/qapi: document the tool that generated the file Alex Bennée
2023-05-06 7:34 ` Markus Armbruster
2023-05-05 15:53 ` [PATCH v3 05/10] qapi: make the vcpu parameters deprecated for 8.1 Alex Bennée
2023-05-06 7:20 ` Markus Armbruster [this message]
2023-05-05 15:53 ` [PATCH v3 06/10] trace: remove code that depends on setting vcpu Alex Bennée
2023-05-10 7:46 ` Philippe Mathieu-Daudé
2023-05-23 12:11 ` Alex Bennée
2023-05-05 15:53 ` [PATCH v3 07/10] trace: remove control-vcpu.h Alex Bennée
2023-05-05 15:53 ` [PATCH v3 08/10] tcg: remove the final vestiges of dstate Alex Bennée
2023-05-10 7:48 ` Philippe Mathieu-Daudé
2023-05-05 15:53 ` [PATCH v3 09/10] hw/9pfs: use qemu_xxhash4 Alex Bennée
2023-05-05 15:53 ` [PATCH v3 10/10] accel/tcg: include cs_base in our hash calculations Alex Bennée
2023-05-05 18:27 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a5yirkmp.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=groug@kaod.org \
--cc=imp@bsdimp.com \
--cc=kevans@freebsd.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
--cc=richard.henderson@linaro.org \
--cc=riku.voipio@iki.fi \
--cc=stefanha@redhat.com \
--cc=wangyanan55@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.