From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
pbonzini@redhat.com, qemu-devel@nongnu.org,
richard.henderson@linaro.org
Subject: Re: [PATCH v3 1/8] reset: allow registering handlers that aren't called by snapshot loading
Date: Mon, 24 Oct 2022 15:19:55 +0200 [thread overview]
Message-ID: <8735bd8ikk.fsf@pond.sub.org> (raw)
In-Reply-To: <CAFEAcA-TT_zRZQ076k6thP2ANk07EqMg8u7MP_6j24u2CCiEGA@mail.gmail.com> (Peter Maydell's message of "Mon, 24 Oct 2022 13:39:49 +0100")
Peter Maydell <peter.maydell@linaro.org> writes:
> On Mon, 24 Oct 2022 at 13:28, Markus Armbruster <armbru@redhat.com> wrote:
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> > Markus: if we add a new value to the ShutdownCause enumeration,
>> > how annoying is it if we decide we don't want it later? I guess
>> > we can just leave it in the enum unused... (In this case we're
>> > using it for purely internal purposes and it won't ever actually
>> > wind up in any QMP events.)
>>
>> Deleting enumeration values is a compatibility issue only if the value
>> is usable in QMP input.
>>
>> "Purely internal" means it cannot occur in QMP output, and any attempt
>> to use it in input fails. Aside: feels a bit fragile.
>
> In this case there are as far as I can see no QMP input commands
> which use the enum at all -- it's only used in events, which are
> always output, I think.
They are.
Ascertaining "not used in QMP input" is pretty easy, and "not used in
CLI" isn't hard. My point is that uses could creep in later. This is
what makes "purely internal" fragile.
next prev parent reply other threads:[~2022-10-24 13:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-14 2:16 [PATCH v3 0/8] rerandomize RNG seeds on reboot and handle record&replay Jason A. Donenfeld
2022-10-14 2:16 ` [PATCH v3 1/8] reset: allow registering handlers that aren't called by snapshot loading Jason A. Donenfeld
2022-10-24 11:06 ` Peter Maydell
2022-10-24 12:00 ` Jason A. Donenfeld
2022-10-24 12:28 ` Markus Armbruster
2022-10-24 12:39 ` Peter Maydell
2022-10-24 13:19 ` Markus Armbruster [this message]
2022-10-24 14:27 ` Peter Maydell
2022-10-24 17:39 ` Markus Armbruster
2022-10-25 0:56 ` Jason A. Donenfeld
2022-10-14 2:16 ` [PATCH v3 2/8] x86: do not re-randomize RNG seed on snapshot load Jason A. Donenfeld
2022-10-14 2:16 ` [PATCH v3 3/8] device-tree: add re-randomization helper function Jason A. Donenfeld
2022-10-14 2:16 ` [PATCH v3 4/8] arm: re-randomize rng-seed on reboot Jason A. Donenfeld
2022-10-14 2:16 ` [PATCH v3 5/8] riscv: " Jason A. Donenfeld
2022-10-14 2:16 ` [PATCH v3 6/8] openrisc: " Jason A. Donenfeld
2022-10-15 16:52 ` Stafford Horne
2022-10-14 2:16 ` [PATCH v3 7/8] rx: " Jason A. Donenfeld
2022-10-14 2:16 ` [PATCH v3 8/8] mips: " Jason A. Donenfeld
2022-10-20 17:38 ` [PATCH v3 0/8] rerandomize RNG seeds on reboot and handle record&replay Jason A. Donenfeld
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=8735bd8ikk.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=Jason@zx2c4.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).