[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machine types pc-0.10 an
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machine types pc-0.10 and pc-0.11 |
Date: |
Mon, 11 Jun 2018 19:18:59 -0300 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
On Mon, Jun 11, 2018 at 05:41:04AM +0200, Thomas Huth wrote:
> The oldest machine type which is still used in a maintained distribution
> is a pc-0.12 based machine type in RHEL6, so everything that is older
> than pc-0.12 should not be used anymore. Thus let's deprecate pc-0.10
> and pc-0.11 so that we can finally remove them in a future release.
>
> Signed-off-by: Thomas Huth <address@hidden>
> ---
> This is based on a patch that I already sent in 2017. But back then, we
> were still in progress of discussing our deprecation policies (e.g. auto-
> matic deprecation for old machine types), and there was no clear consensus
> whether we should deprecate 0.10 - 0.11, all 0.x or even up to version 1.2.
> After some iterations and too much discussion, I've forgotten about this
> patch. Anyway, I think we agreed that at least 0.10 and 0.11 can certainly
> be removed nowadays, so let's finally get at least those two machine types
> marked as deprecated! If that works fine and we will finally have removed
> these two types in v3.2, we can resume the discussion about newer machine
> types afterwards.
Thanks!
>
> hw/i386/pc_piix.c | 2 ++
> include/hw/boards.h | 1 +
> qemu-doc.texi | 5 +++++
> vl.c | 9 +++++++--
> 4 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 3d81136..fa61dc3 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -955,6 +955,8 @@ static void pc_i440fx_0_11_machine_options(MachineClass
> *m)
> {
> pc_i440fx_0_12_machine_options(m);
> m->hw_version = "0.11";
> + m->deprecation_msg = "Old and unsupported machine version, "
> + "use a newer machine type instead.";
Sounds simple enough to me, but see comment about QMP below.
> SET_MACHINE_COMPAT(m, PC_COMPAT_0_11);
> }
>
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index ef7457f..e1bd25f 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -166,6 +166,7 @@ struct MachineClass {
> char *name;
> const char *alias;
> const char *desc;
> + const char *deprecation_msg;
Let's document guidelines for deprecation_msg to avoid the
inconsistencies we saw in previous proposals?
>
> void (*init)(MachineState *state);
> void (*reset)(void);
> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index 2effe66..2a597d6 100644
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -2965,6 +2965,11 @@ support page sizes < 4096 any longer.
>
> @section System emulator machines
>
> address@hidden pc-0.10 and pc-0.11 (since 3.0)
> +
> +These machine types are very old and likely can not be used for
> life-migration
^^^^
"live"
I never know if the right way to spell it is "live-migration" or
"live migration".
> +from old QEMU versions anymore. A newer machine type should be used instead.
> +
> @section Block device options
>
> @subsection "backing": "" (since 2.12.0)
> diff --git a/vl.c b/vl.c
> index 0603171..096814c 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2560,8 +2560,9 @@ static gint machine_class_cmp(gconstpointer a,
> gconstpointer b)
> if (mc->alias) {
> printf("%-20s %s (alias of %s)\n", mc->alias, mc->desc,
> mc->name);
> }
> - printf("%-20s %s%s\n", mc->name, mc->desc,
> - mc->is_default ? " (default)" : "");
> + printf("%-20s %s%s%s\n", mc->name, mc->desc,
> + mc->is_default ? " (default)" : "",
> + mc->deprecation_msg ? " (deprecated)" : "");
> }
> }
>
> @@ -3952,6 +3953,10 @@ int main(int argc, char **argv, char **envp)
> }
>
> machine_class = select_machine();
> + if (machine_class->deprecation_msg) {
> + error_report("Machine type '%s' is deprecated: %s",
> + machine_class->name, machine_class->deprecation_msg);
> + }
Do you plan to add this info to 'query-machines' QMP command?
If we do that, maybe we should represent the common "this machine
type is too old, but there's a new version" case in a more
machine-friendly way? Maybe a 'deprecation_reason' enum would be
better than a 'deprecation_msg' field?
(Note that I don't think any discussions about the QMP interface
should block this patch from being merged. We can deprecate the
machines first, and decide about QMP later.)
>
> set_memory_options(&ram_slots, &maxram_size, machine_class);
>
> --
> 1.8.3.1
>
--
Eduardo