Re: [Qemu-devel] [PATCH] hw/i386: Deprecate the machine types pc-0.10 and pc-0.11

[Markus Armbruster]

Eduardo Habkost <address@hidden> writes:

> 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/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?

QMP needs a generic mechanism to communicate "FOO is deprecated, use BAR
instead".

> (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.)

Yes.

>>  
>>      set_memory_options(&ram_slots, &maxram_size, machine_class);
>>  
>> -- 
>> 1.8.3.1
>>