[Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Thomas Huth]

We don't want to carry along old machine types forever. If we are able to
remove the pc machines up to 0.13 one day for example, this would allow
us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
BARs directly to low memory). Everything up to pc-1.2 is also known to
have issues with migration.  So let's start with a deprecation message
for the old machine types so that the (hopefully) few users of these old
systems start switching over to newer machine types instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 Note: Even if we mark all these old machines as deprecated, this ofcourse
 doesn't mean that we also have to remove them all at once later when we
 decide to finally really remove some. We could then also start by removing
 0.10 and 0.11 only, for example (since there should really be no users left
 for these), or only up to 0.13 (to be able to kill rombar=0).

 v3:
 - Use a more generic approach by introducing a "deprecation_msg" in the
   MachineClass instead.

 v2:
 - Deprecate machines up to pc-1.2

 hw/i386/pc_piix.c   | 1 +
 include/hw/boards.h | 1 +
 vl.c                | 4 ++++
 3 files changed, 6 insertions(+)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 22dbef6..8e70308 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -707,6 +707,7 @@ static void pc_i440fx_1_2_machine_options(MachineClass *m)
 {
     pc_i440fx_1_3_machine_options(m);
     m->hw_version = "1.2.0";
+    m->deprecation_msg = "Please use a newer machine type instead.";
     SET_MACHINE_COMPAT(m, PC_COMPAT_1_2);
 }
 
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 76ce021..42a0264 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -112,6 +112,7 @@ struct MachineClass {
     char *name;
     const char *alias;
     const char *desc;
+    const char *deprecation_msg;
 
     void (*init)(MachineState *state);
     void (*reset)(void);
diff --git a/vl.c b/vl.c
index f7560de..0058d41 100644
--- a/vl.c
+++ b/vl.c
@@ -4115,6 +4115,10 @@ int main(int argc, char **argv, char **envp)
     replay_configure(icount_opts);
 
     machine_class = select_machine();
+    if (machine_class->deprecation_msg) {
+        error_report("Machine type '%s' is deprecated. %s",
+                     machine_class->name, machine_class->deprecation_msg);
+    }
 
     set_memory_options(&ram_slots, &maxram_size, machine_class);
 
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Gerd Hoffmann]

On Wed, 2017-07-12 at 10:22 +0200, Thomas Huth wrote:
> We don't want to carry along old machine types forever. If we are
> able to
> remove the pc machines up to 0.13 one day for example, this would
> allow
> us to eventually kill the code for rombar=0 (i.e. where QEMU copies
> ROM
> BARs directly to low memory). Everything up to pc-1.2 is also known
> to
> have issues with migration.  So let's start with a deprecation
> message
> for the old machine types so that the (hopefully) few users of these
> old
> systems start switching over to newer machine types instead.

Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Eduardo Habkost]

On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> We don't want to carry along old machine types forever. If we are able to
> remove the pc machines up to 0.13 one day for example, this would allow
> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> BARs directly to low memory). Everything up to pc-1.2 is also known to
> have issues with migration.  So let's start with a deprecation message
> for the old machine types so that the (hopefully) few users of these old
> systems start switching over to newer machine types instead.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>

Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>

I suggest changing "-machine help" too.  Today it looks like this:

  Supported machines are:
  pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
  pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
  pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
  pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
  pc-1.3               Standard PC (i440FX + PIIX, 1996)
  pc-1.2               Standard PC (i440FX + PIIX, 1996)
  pc-1.1               Standard PC (i440FX + PIIX, 1996)
  pc-1.0               Standard PC (i440FX + PIIX, 1996)
  pc-0.15              Standard PC (i440FX + PIIX, 1996)
  pc-0.14              Standard PC (i440FX + PIIX, 1996)
  pc-0.13              Standard PC (i440FX + PIIX, 1996)
  pc-0.12              Standard PC (i440FX + PIIX, 1996)
  pc-0.11              Standard PC (i440FX + PIIX, 1996)
  pc-0.10              Standard PC (i440FX + PIIX, 1996)
  pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
  pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
  pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
  pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
  pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
  pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
  q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
  pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
  isapc                ISA-only PC
  none                 empty machine


It could be changed to something like this:

  Supported machines are:
  pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
  pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
  pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
  pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
  pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
  pc-1.3               Standard PC (i440FX + PIIX, 1996)
  pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
  pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
  pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
  pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
  pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
  pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
  q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
  pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
  isapc                ISA-only PC
  none                 empty machine

  Deprecated machines: pc-1.2, pc-1.1, pc-1.0, pc-0.15, pc-0.14, pc-0.13,
                       pc-0.12, pc-0.11, pc-0.10.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Daniel P. Berrange]

On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> We don't want to carry along old machine types forever. If we are able to
> remove the pc machines up to 0.13 one day for example, this would allow
> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> BARs directly to low memory). Everything up to pc-1.2 is also known to
> have issues with migration.  So let's start with a deprecation message
> for the old machine types so that the (hopefully) few users of these old
> systems start switching over to newer machine types instead.

I think we must document & agree on our support policy for machine
types, before we start marking them as deprecated. eg please consider
the following document before accepting this deprecation patch:

 https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00652.html

Note in that proposal there, I say we do *not* go through trouble of
explicitly marking machines as deprecated. We just document upfront
the intended lifecycle and then delete them when it is done.

Just use deprecation warnings for things where there is no predictable
lifecycle upfront.

> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  Note: Even if we mark all these old machines as deprecated, this ofcourse
>  doesn't mean that we also have to remove them all at once later when we
>  decide to finally really remove some. We could then also start by removing
>  0.10 and 0.11 only, for example (since there should really be no users left
>  for these), or only up to 0.13 (to be able to kill rombar=0).
> 
>  v3:
>  - Use a more generic approach by introducing a "deprecation_msg" in the
>    MachineClass instead.
> 
>  v2:
>  - Deprecate machines up to pc-1.2
> 
>  hw/i386/pc_piix.c   | 1 +
>  include/hw/boards.h | 1 +
>  vl.c                | 4 ++++
>  3 files changed, 6 insertions(+)

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Michael S. Tsirkin]

On Wed, Jul 12, 2017 at 11:51:21AM -0300, Eduardo Habkost wrote:
> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> > We don't want to carry along old machine types forever. If we are able to
> > remove the pc machines up to 0.13 one day for example, this would allow
> > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> > BARs directly to low memory). Everything up to pc-1.2 is also known to
> > have issues with migration.  So let's start with a deprecation message
> > for the old machine types so that the (hopefully) few users of these old
> > systems start switching over to newer machine types instead.
> > 
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> 
> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> 
> I suggest changing "-machine help" too.  Today it looks like this:
> 
>   Supported machines are:
>   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
>   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
>   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
>   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
>   pc-1.3               Standard PC (i440FX + PIIX, 1996)
>   pc-1.2               Standard PC (i440FX + PIIX, 1996)
>   pc-1.1               Standard PC (i440FX + PIIX, 1996)
>   pc-1.0               Standard PC (i440FX + PIIX, 1996)
>   pc-0.15              Standard PC (i440FX + PIIX, 1996)
>   pc-0.14              Standard PC (i440FX + PIIX, 1996)
>   pc-0.13              Standard PC (i440FX + PIIX, 1996)
>   pc-0.12              Standard PC (i440FX + PIIX, 1996)
>   pc-0.11              Standard PC (i440FX + PIIX, 1996)
>   pc-0.10              Standard PC (i440FX + PIIX, 1996)
>   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
>   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
>   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
>   isapc                ISA-only PC
>   none                 empty machine

Any chance we can sort them reasonably too?

> 
> It could be changed to something like this:
> 
>   Supported machines are:
>   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
>   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
>   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
>   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
>   pc-1.3               Standard PC (i440FX + PIIX, 1996)
>   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
>   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
>   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
>   isapc                ISA-only PC
>   none                 empty machine
> 
>   Deprecated machines: pc-1.2, pc-1.1, pc-1.0, pc-0.15, pc-0.14, pc-0.13,
>                        pc-0.12, pc-0.11, pc-0.10.
> 
> -- 
> Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Markus Armbruster]

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
>> We don't want to carry along old machine types forever. If we are able to
>> remove the pc machines up to 0.13 one day for example, this would allow
>> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
>> BARs directly to low memory). Everything up to pc-1.2 is also known to
>> have issues with migration.  So let's start with a deprecation message
>> for the old machine types so that the (hopefully) few users of these old
>> systems start switching over to newer machine types instead.
>> 
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>
> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>
> I suggest changing "-machine help" too.  Today it looks like this:
>
>   Supported machines are:
>   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
>   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
>   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
>   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
>   pc-1.3               Standard PC (i440FX + PIIX, 1996)
>   pc-1.2               Standard PC (i440FX + PIIX, 1996)
>   pc-1.1               Standard PC (i440FX + PIIX, 1996)
>   pc-1.0               Standard PC (i440FX + PIIX, 1996)
>   pc-0.15              Standard PC (i440FX + PIIX, 1996)
>   pc-0.14              Standard PC (i440FX + PIIX, 1996)
>   pc-0.13              Standard PC (i440FX + PIIX, 1996)
>   pc-0.12              Standard PC (i440FX + PIIX, 1996)
>   pc-0.11              Standard PC (i440FX + PIIX, 1996)
>   pc-0.10              Standard PC (i440FX + PIIX, 1996)
>   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
>   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
>   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
>   isapc                ISA-only PC
>   none                 empty machine
>
>
> It could be changed to something like this:
>
>   Supported machines are:
>   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
>   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
>   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
>   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
>   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
>   pc-1.3               Standard PC (i440FX + PIIX, 1996)
>   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
>   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
>   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
>   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
>   isapc                ISA-only PC
>   none                 empty machine
>
>   Deprecated machines: pc-1.2, pc-1.1, pc-1.0, pc-0.15, pc-0.14, pc-0.13,
>                        pc-0.12, pc-0.11, pc-0.10.

I'd add "(deprecated)" to the existing lines instead.  Probably simpler
to code, because it's consistent with the existing format.

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Thomas Huth]

On 12.07.2017 17:04, Daniel P. Berrange wrote:
> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
>> We don't want to carry along old machine types forever. If we are able to
>> remove the pc machines up to 0.13 one day for example, this would allow
>> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
>> BARs directly to low memory). Everything up to pc-1.2 is also known to
>> have issues with migration.  So let's start with a deprecation message
>> for the old machine types so that the (hopefully) few users of these old
>> systems start switching over to newer machine types instead.
> 
> I think we must document & agree on our support policy for machine
> types, before we start marking them as deprecated. eg please consider
> the following document before accepting this deprecation patch:
> 
>  https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00652.html
> 
> Note in that proposal there, I say we do *not* go through trouble of
> explicitly marking machines as deprecated. We just document upfront
> the intended lifecycle and then delete them when it is done.
> 
> Just use deprecation warnings for things where there is no predictable
> lifecycle upfront.

I'm still not 100% sure whether that auto-deprecation of machine types
is such a good idea ... since we might need to maintain machines in
downstream a little bit longer than specified there, it might be better
to rather deprecate them manually from time to time.

Anyway, concerning my patch - I'll stop here and won't send another
version. There is too much bikeshed painting going on in this area for
my taste, and since I'm rather a powerpc / s390x guy, I'm also fine if
the pc-0.x machines stay around forever. If somebody else wants to push
this topic instead, feel free to do so.

 Thomas

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Daniel P. Berrange]

On Wed, Jul 12, 2017 at 06:00:46PM +0200, Thomas Huth wrote:
> On 12.07.2017 17:04, Daniel P. Berrange wrote:
> > On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> >> We don't want to carry along old machine types forever. If we are able to
> >> remove the pc machines up to 0.13 one day for example, this would allow
> >> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> >> BARs directly to low memory). Everything up to pc-1.2 is also known to
> >> have issues with migration.  So let's start with a deprecation message
> >> for the old machine types so that the (hopefully) few users of these old
> >> systems start switching over to newer machine types instead.
> > 
> > I think we must document & agree on our support policy for machine
> > types, before we start marking them as deprecated. eg please consider
> > the following document before accepting this deprecation patch:
> > 
> >  https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00652.html
> > 
> > Note in that proposal there, I say we do *not* go through trouble of
> > explicitly marking machines as deprecated. We just document upfront
> > the intended lifecycle and then delete them when it is done.
> > 
> > Just use deprecation warnings for things where there is no predictable
> > lifecycle upfront.
> 
> I'm still not 100% sure whether that auto-deprecation of machine types
> is such a good idea ... since we might need to maintain machines in
> downstream a little bit longer than specified there, it might be better
> to rather deprecate them manually from time to time.

Downstreams usually maintain custom machine types, so fact that the
upstream machine types get deleted is not a problem in itself. The problem
comes if followup internal code removal then prevents downstream from
creating their custom machine type.  I don't think we need tie these
issues together. We can remove old machine types, without immediately
removing features that our harm creation of downstream machine types.

> Anyway, concerning my patch - I'll stop here and won't send another
> version. There is too much bikeshed painting going on in this area for
> my taste, and since I'm rather a powerpc / s390x guy, I'm also fine if
> the pc-0.x machines stay around forever. If somebody else wants to push
> this topic instead, feel free to do so.

FWIW, I think your proposals have been very useful in general. It has
been way overdue to have this kind of discussion. I just want us to
focus on defining a policy, rather than making adhoc decisions each
time around, as the later is rather unpredictable for users of qemu.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Thomas Huth]

On 12.07.2017 18:12, Daniel P. Berrange wrote:
> On Wed, Jul 12, 2017 at 06:00:46PM +0200, Thomas Huth wrote:
>> On 12.07.2017 17:04, Daniel P. Berrange wrote:
[...]
>>> I think we must document & agree on our support policy for machine
>>> types, before we start marking them as deprecated. eg please consider
>>> the following document before accepting this deprecation patch:
>>>
>>>  https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00652.html
>>>
>>> Note in that proposal there, I say we do *not* go through trouble of
>>> explicitly marking machines as deprecated. We just document upfront
>>> the intended lifecycle and then delete them when it is done.
>>>
>>> Just use deprecation warnings for things where there is no predictable
>>> lifecycle upfront.
>>
>> I'm still not 100% sure whether that auto-deprecation of machine types
>> is such a good idea ... since we might need to maintain machines in
>> downstream a little bit longer than specified there, it might be better
>> to rather deprecate them manually from time to time.
> 
> Downstreams usually maintain custom machine types, so fact that the
> upstream machine types get deleted is not a problem in itself. The problem
> comes if followup internal code removal then prevents downstream from
> creating their custom machine type.

Right, that's what I had in mind.

> I don't think we need tie these
> issues together. We can remove old machine types, without immediately
> removing features that our harm creation of downstream machine types.

I think that won't work. Either the required code gets removed by
accident, or if not, we forget to remove it later, once downstream does
not require it anymore. I think it is better to remove machine types and
the related features code in the upstream code base in one shot. So
manually deprecating machine types and carefully removing them later
sounds like the better approach to me.

> FWIW, I think your proposals have been very useful in general. It has
> been way overdue to have this kind of discussion. I just want us to
> focus on defining a policy, rather than making adhoc decisions each
> time around, as the later is rather unpredictable for users of qemu.

Well, I think your doc updates are also a very good idea, but we could
simply state that we keep the old machine types around for *at least* x
releases or y years. That should give users the same safety as when
we're declaring that old machine types will definitely be removed after
x releases or y years.

 Thomas

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Paolo Bonzini]

On 12/07/2017 18:12, Daniel P. Berrange wrote:
>> I'm still not 100% sure whether that auto-deprecation of machine types
>> is such a good idea ... since we might need to maintain machines in
>> downstream a little bit longer than specified there, it might be better
>> to rather deprecate them manually from time to time.
> 
> Downstreams usually maintain custom machine types, so fact that the
> upstream machine types get deleted is not a problem in itself. The problem
> comes if followup internal code removal then prevents downstream from
> creating their custom machine type.  I don't think we need tie these
> issues together. We can remove old machine types, without immediately
> removing features that our harm creation of downstream machine types.

I think machine type and feature removal should be tied together.

Doing the opposite leaves around code that is more or less dead from an
upstream point of view, and looks like an ad hoc rule for Red Hat.  It
harms downstreams that do not participate in upstream development
(though perhaps this is an intended side effect?).

Paolo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Daniel P. Berrange]

On Wed, Jul 12, 2017 at 06:23:51PM +0200, Paolo Bonzini wrote:
> On 12/07/2017 18:12, Daniel P. Berrange wrote:
> >> I'm still not 100% sure whether that auto-deprecation of machine types
> >> is such a good idea ... since we might need to maintain machines in
> >> downstream a little bit longer than specified there, it might be better
> >> to rather deprecate them manually from time to time.
> > 
> > Downstreams usually maintain custom machine types, so fact that the
> > upstream machine types get deleted is not a problem in itself. The problem
> > comes if followup internal code removal then prevents downstream from
> > creating their custom machine type.  I don't think we need tie these
> > issues together. We can remove old machine types, without immediately
> > removing features that our harm creation of downstream machine types.
> 
> I think machine type and feature removal should be tied together.
> 
> Doing the opposite leaves around code that is more or less dead from an
> upstream point of view, and looks like an ad hoc rule for Red Hat.  It
> harms downstreams that do not participate in upstream development
> (though perhaps this is an intended side effect?).

Yep, I'm amenable to that POV too. It is entirely valid to say that if
downstream distros need to care about such ancient back-compat, then they
will just have to do the extra work to use git history to undelete any bits
they need that upstream has discarded.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Daniel P. Berrange]

On Wed, Jul 12, 2017 at 06:23:39PM +0200, Thomas Huth wrote:
> On 12.07.2017 18:12, Daniel P. Berrange wrote:
> > On Wed, Jul 12, 2017 at 06:00:46PM +0200, Thomas Huth wrote:
> >> On 12.07.2017 17:04, Daniel P. Berrange wrote:
> [...]
> >>> I think we must document & agree on our support policy for machine
> >>> types, before we start marking them as deprecated. eg please consider
> >>> the following document before accepting this deprecation patch:
> >>>
> >>>  https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00652.html
> >>>
> >>> Note in that proposal there, I say we do *not* go through trouble of
> >>> explicitly marking machines as deprecated. We just document upfront
> >>> the intended lifecycle and then delete them when it is done.
> >>>
> >>> Just use deprecation warnings for things where there is no predictable
> >>> lifecycle upfront.
> >>
> >> I'm still not 100% sure whether that auto-deprecation of machine types
> >> is such a good idea ... since we might need to maintain machines in
> >> downstream a little bit longer than specified there, it might be better
> >> to rather deprecate them manually from time to time.
> > 
> > Downstreams usually maintain custom machine types, so fact that the
> > upstream machine types get deleted is not a problem in itself. The problem
> > comes if followup internal code removal then prevents downstream from
> > creating their custom machine type.
> 
> Right, that's what I had in mind.
> 
> > I don't think we need tie these
> > issues together. We can remove old machine types, without immediately
> > removing features that our harm creation of downstream machine types.
> 
> I think that won't work. Either the required code gets removed by
> accident, or if not, we forget to remove it later, once downstream does
> not require it anymore. I think it is better to remove machine types and
> the related features code in the upstream code base in one shot. So
> manually deprecating machine types and carefully removing them later
> sounds like the better approach to me.
> 
> > FWIW, I think your proposals have been very useful in general. It has
> > been way overdue to have this kind of discussion. I just want us to
> > focus on defining a policy, rather than making adhoc decisions each
> > time around, as the later is rather unpredictable for users of qemu.
> 
> Well, I think your doc updates are also a very good idea, but we could
> simply state that we keep the old machine types around for *at least* x
> releases or y years. That should give users the same safety as when
> we're declaring that old machine types will definitely be removed after
> x releases or y years.

I really don't like saying "at least", as it means every time we want
to actually delete something that we have previously deprecated, we
have to have a debate about whether it can actually go and make an
arbitrary decision about whether to accept someone's objection to
the deletion. Giving a clear finite timeframe sets expectations
right from the start, and avoids us playing favourites to particular
people who want stuff kept around

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Eduardo Habkost]

On Wed, Jul 12, 2017 at 05:45:30PM +0200, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
[...]
> > It could be changed to something like this:
> >
> >   Supported machines are:
> >   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
> >   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
> >   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
> >   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
> >   pc-1.3               Standard PC (i440FX + PIIX, 1996)
> >   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
> >   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
> >   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
> >   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
> >   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
> >   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
> >   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
> >   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
> >   isapc                ISA-only PC
> >   none                 empty machine
> >
> >   Deprecated machines: pc-1.2, pc-1.1, pc-1.0, pc-0.15, pc-0.14, pc-0.13,
> >                        pc-0.12, pc-0.11, pc-0.10.
> 
> I'd add "(deprecated)" to the existing lines instead.  Probably simpler
> to code, because it's consistent with the existing format.

That would be good enough to me, and probably a one-line patch.
My intention was to hide the deprecated machines in a corner,
separated from the "Supported machines" list.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Eduardo Habkost]

On Wed, Jul 12, 2017 at 06:17:55PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 12, 2017 at 11:51:21AM -0300, Eduardo Habkost wrote:
> > On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> > > We don't want to carry along old machine types forever. If we are able to
> > > remove the pc machines up to 0.13 one day for example, this would allow
> > > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> > > BARs directly to low memory). Everything up to pc-1.2 is also known to
> > > have issues with migration.  So let's start with a deprecation message
> > > for the old machine types so that the (hopefully) few users of these old
> > > systems start switching over to newer machine types instead.
> > > 
> > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > 
> > Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> > 
> > I suggest changing "-machine help" too.  Today it looks like this:
> > 
> >   Supported machines are:
> >   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
> >   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
> >   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
> >   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
> >   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
> >   pc-1.3               Standard PC (i440FX + PIIX, 1996)
> >   pc-1.2               Standard PC (i440FX + PIIX, 1996)
> >   pc-1.1               Standard PC (i440FX + PIIX, 1996)
> >   pc-1.0               Standard PC (i440FX + PIIX, 1996)
> >   pc-0.15              Standard PC (i440FX + PIIX, 1996)
> >   pc-0.14              Standard PC (i440FX + PIIX, 1996)
> >   pc-0.13              Standard PC (i440FX + PIIX, 1996)
> >   pc-0.12              Standard PC (i440FX + PIIX, 1996)
> >   pc-0.11              Standard PC (i440FX + PIIX, 1996)
> >   pc-0.10              Standard PC (i440FX + PIIX, 1996)
> >   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
> >   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
> >   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
> >   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
> >   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
> >   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
> >   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
> >   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
> >   isapc                ISA-only PC
> >   none                 empty machine
> 
> Any chance we can sort them reasonably too?

If we use strverscmp(), it will be sorted in a more reasonable
way.  We could copy the gnulib version on systems without glibc.
Life is too short for writing configure checks by hand, though; I
will add this to the end of my wish-todo list.  If somebody wants
to volunteer, be my guest.

I'm CCing Eric in case he has suggestions that would help import
the gnulib module in an easy way.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Eduardo Habkost]

On Wed, Jul 12, 2017 at 04:04:00PM +0100, Daniel P. Berrange wrote:
> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> > We don't want to carry along old machine types forever. If we are able to
> > remove the pc machines up to 0.13 one day for example, this would allow
> > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> > BARs directly to low memory). Everything up to pc-1.2 is also known to
> > have issues with migration.  So let's start with a deprecation message
> > for the old machine types so that the (hopefully) few users of these old
> > systems start switching over to newer machine types instead.
> 
> I think we must document & agree on our support policy for machine
> types, before we start marking them as deprecated. eg please consider
> the following document before accepting this deprecation patch:
> 
>  https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00652.html
> 
> Note in that proposal there, I say we do *not* go through trouble of
> explicitly marking machines as deprecated. We just document upfront
> the intended lifecycle and then delete them when it is done.
> 
> Just use deprecation warnings for things where there is no predictable
> lifecycle upfront.

I'd bet most people won't read the deprecation policy
documentation, and a deprecation warning for 1 or 2 releases
would be still useful before we finally remove a machine-type.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Michael S. Tsirkin]

On Wed, Jul 12, 2017 at 05:15:50PM -0300, Eduardo Habkost wrote:
> On Wed, Jul 12, 2017 at 06:17:55PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 12, 2017 at 11:51:21AM -0300, Eduardo Habkost wrote:
> > > On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> > > > We don't want to carry along old machine types forever. If we are able to
> > > > remove the pc machines up to 0.13 one day for example, this would allow
> > > > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> > > > BARs directly to low memory). Everything up to pc-1.2 is also known to
> > > > have issues with migration.  So let's start with a deprecation message
> > > > for the old machine types so that the (hopefully) few users of these old
> > > > systems start switching over to newer machine types instead.
> > > > 
> > > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > 
> > > Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> > > 
> > > I suggest changing "-machine help" too.  Today it looks like this:
> > > 
> > >   Supported machines are:
> > >   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
> > >   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
> > >   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
> > >   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
> > >   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
> > >   pc-1.3               Standard PC (i440FX + PIIX, 1996)
> > >   pc-1.2               Standard PC (i440FX + PIIX, 1996)
> > >   pc-1.1               Standard PC (i440FX + PIIX, 1996)
> > >   pc-1.0               Standard PC (i440FX + PIIX, 1996)
> > >   pc-0.15              Standard PC (i440FX + PIIX, 1996)
> > >   pc-0.14              Standard PC (i440FX + PIIX, 1996)
> > >   pc-0.13              Standard PC (i440FX + PIIX, 1996)
> > >   pc-0.12              Standard PC (i440FX + PIIX, 1996)
> > >   pc-0.11              Standard PC (i440FX + PIIX, 1996)
> > >   pc-0.10              Standard PC (i440FX + PIIX, 1996)
> > >   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
> > >   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
> > >   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
> > >   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
> > >   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
> > >   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
> > >   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
> > >   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
> > >   isapc                ISA-only PC
> > >   none                 empty machine
> > 
> > Any chance we can sort them reasonably too?
> 
> If we use strverscmp(), it will be sorted in a more reasonable
> way.  We could copy the gnulib version on systems without glibc.
> Life is too short for writing configure checks by hand, though; I
> will add this to the end of my wish-todo list.  If somebody wants
> to volunteer, be my guest.
> 
> I'm CCing Eric in case he has suggestions that would help import
> the gnulib module in an easy way.
> 
> -- 
> Eduardo

As we never have leading zeroes, and input comes from QEMU so
it's safe, it's probably easier to just open-code it:

/* compare string numerically: shorter strings give smaller numbers */
int mstcmp(const char *s1, const char *s2)
{
	int l1, l2;

	l1 = strlen(s1);
	l2 = strlen(s2);
	return l1 == l2 ? strcmp(s1, s2) : l1 - l2;
}

feel free to rename and include.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

-- 
MST

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Eduardo Habkost]

On Wed, Jul 12, 2017 at 05:29:01PM +0100, Daniel P. Berrange wrote:
> On Wed, Jul 12, 2017 at 06:23:51PM +0200, Paolo Bonzini wrote:
> > On 12/07/2017 18:12, Daniel P. Berrange wrote:
> > >> I'm still not 100% sure whether that auto-deprecation of machine types
> > >> is such a good idea ... since we might need to maintain machines in
> > >> downstream a little bit longer than specified there, it might be better
> > >> to rather deprecate them manually from time to time.
> > > 
> > > Downstreams usually maintain custom machine types, so fact that the
> > > upstream machine types get deleted is not a problem in itself. The problem
> > > comes if followup internal code removal then prevents downstream from
> > > creating their custom machine type.  I don't think we need tie these
> > > issues together. We can remove old machine types, without immediately
> > > removing features that our harm creation of downstream machine types.
> > 
> > I think machine type and feature removal should be tied together.
> > 
> > Doing the opposite leaves around code that is more or less dead from an
> > upstream point of view, and looks like an ad hoc rule for Red Hat.  It
> > harms downstreams that do not participate in upstream development
> > (though perhaps this is an intended side effect?).
> 
> Yep, I'm amenable to that POV too. It is entirely valid to say that if
> downstream distros need to care about such ancient back-compat, then they
> will just have to do the extra work to use git history to undelete any bits
> they need that upstream has discarded.

If they do this, won't it be better to cooperate and let those
bits to be maintained in the upstream tree (as long as somebody
is willing to maintain them), instead of being kept in their own
downstream fork?

(That doesn't mean we shouldn't have a deprecation policy, but
that I would prefer to have the deprecation policy amended if
necessary than having a diverging fork maintained by a downstream
distro).

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Eduardo Habkost]

On Wed, Jul 12, 2017 at 11:31:59PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 12, 2017 at 05:15:50PM -0300, Eduardo Habkost wrote:
> > On Wed, Jul 12, 2017 at 06:17:55PM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jul 12, 2017 at 11:51:21AM -0300, Eduardo Habkost wrote:
> > > > On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> > > > > We don't want to carry along old machine types forever. If we are able to
> > > > > remove the pc machines up to 0.13 one day for example, this would allow
> > > > > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> > > > > BARs directly to low memory). Everything up to pc-1.2 is also known to
> > > > > have issues with migration.  So let's start with a deprecation message
> > > > > for the old machine types so that the (hopefully) few users of these old
> > > > > systems start switching over to newer machine types instead.
> > > > > 
> > > > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > > 
> > > > Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > 
> > > > I suggest changing "-machine help" too.  Today it looks like this:
> > > > 
> > > >   Supported machines are:
> > > >   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
> > > >   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
> > > >   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
> > > >   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
> > > >   pc-1.3               Standard PC (i440FX + PIIX, 1996)
> > > >   pc-1.2               Standard PC (i440FX + PIIX, 1996)
> > > >   pc-1.1               Standard PC (i440FX + PIIX, 1996)
> > > >   pc-1.0               Standard PC (i440FX + PIIX, 1996)
> > > >   pc-0.15              Standard PC (i440FX + PIIX, 1996)
> > > >   pc-0.14              Standard PC (i440FX + PIIX, 1996)
> > > >   pc-0.13              Standard PC (i440FX + PIIX, 1996)
> > > >   pc-0.12              Standard PC (i440FX + PIIX, 1996)
> > > >   pc-0.11              Standard PC (i440FX + PIIX, 1996)
> > > >   pc-0.10              Standard PC (i440FX + PIIX, 1996)
> > > >   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
> > > >   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
> > > >   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
> > > >   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
> > > >   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
> > > >   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
> > > >   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
> > > >   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
> > > >   isapc                ISA-only PC
> > > >   none                 empty machine
> > > 
> > > Any chance we can sort them reasonably too?
> > 
> > If we use strverscmp(), it will be sorted in a more reasonable
> > way.  We could copy the gnulib version on systems without glibc.
> > Life is too short for writing configure checks by hand, though; I
> > will add this to the end of my wish-todo list.  If somebody wants
> > to volunteer, be my guest.
> > 
> > I'm CCing Eric in case he has suggestions that would help import
> > the gnulib module in an easy way.
> > 
> > -- 
> > Eduardo
> 
> As we never have leading zeroes, and input comes from QEMU so
> it's safe, it's probably easier to just open-code it:
> 
> /* compare string numerically: shorter strings give smaller numbers */
> int mstcmp(const char *s1, const char *s2)
> {
> 	int l1, l2;
> 
> 	l1 = strlen(s1);
> 	l2 = strlen(s2);
> 	return l1 == l2 ? strcmp(s1, s2) : l1 - l2;
> }
> 

This doesn't work because strlen("pc-0.10") > strlen("pc-1.0").

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Michael S. Tsirkin]

On Wed, Jul 12, 2017 at 05:56:46PM -0300, Eduardo Habkost wrote:
> On Wed, Jul 12, 2017 at 11:31:59PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 12, 2017 at 05:15:50PM -0300, Eduardo Habkost wrote:
> > > On Wed, Jul 12, 2017 at 06:17:55PM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 12, 2017 at 11:51:21AM -0300, Eduardo Habkost wrote:
> > > > > On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> > > > > > We don't want to carry along old machine types forever. If we are able to
> > > > > > remove the pc machines up to 0.13 one day for example, this would allow
> > > > > > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> > > > > > BARs directly to low memory). Everything up to pc-1.2 is also known to
> > > > > > have issues with migration.  So let's start with a deprecation message
> > > > > > for the old machine types so that the (hopefully) few users of these old
> > > > > > systems start switching over to newer machine types instead.
> > > > > > 
> > > > > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > > > 
> > > > > Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > > 
> > > > > I suggest changing "-machine help" too.  Today it looks like this:
> > > > > 
> > > > >   Supported machines are:
> > > > >   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
> > > > >   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
> > > > >   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-1.3               Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-1.2               Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-1.1               Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-1.0               Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-0.15              Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-0.14              Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-0.13              Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-0.12              Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-0.11              Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-0.10              Standard PC (i440FX + PIIX, 1996)
> > > > >   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
> > > > >   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
> > > > >   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
> > > > >   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
> > > > >   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
> > > > >   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
> > > > >   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
> > > > >   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
> > > > >   isapc                ISA-only PC
> > > > >   none                 empty machine
> > > > 
> > > > Any chance we can sort them reasonably too?
> > > 
> > > If we use strverscmp(), it will be sorted in a more reasonable
> > > way.  We could copy the gnulib version on systems without glibc.
> > > Life is too short for writing configure checks by hand, though; I
> > > will add this to the end of my wish-todo list.  If somebody wants
> > > to volunteer, be my guest.
> > > 
> > > I'm CCing Eric in case he has suggestions that would help import
> > > the gnulib module in an easy way.
> > > 
> > > -- 
> > > Eduardo
> > 
> > As we never have leading zeroes, and input comes from QEMU so
> > it's safe, it's probably easier to just open-code it:
> > 
> > /* compare string numerically: shorter strings give smaller numbers */
> > int mstcmp(const char *s1, const char *s2)
> > {
> > 	int l1, l2;
> > 
> > 	l1 = strlen(s1);
> > 	l2 = strlen(s2);
> > 	return l1 == l2 ? strcmp(s1, s2) : l1 - l2;
> > }
> > 
> 
> This doesn't work because strlen("pc-0.10") > strlen("pc-1.0").

Oh right. So you need to find dots and split at these points.
Something like the below? Completely untested.

int mstcmp(const char *s1, const char *s2)
{
	const char *e1, *e2;
 	int l1, l2, c;

	do {
		e1 = strchr(s1, '.');
		e2 = strchr(s2, '.');

		l1 = e1 ? e1 - s1 + 1 : strlen(s1);
		l2 = e2 ? e2 - s2 + 1 : strlen(s2);

		/* compare numerically: shorter strings give smaller numbers */
		if (l1 != l2) {
			break;
		}
		c = strncmp(s1, s2, l1);
		if (c) {
			return c;
		}
		s1 += l1;
		s2 += l1;
	} while (l1);

	return l1 - l2;
}



> -- 
> Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Laszlo Ersek]

On 07/13/17 00:27, Michael S. Tsirkin wrote:
> On Wed, Jul 12, 2017 at 05:56:46PM -0300, Eduardo Habkost wrote:
>> On Wed, Jul 12, 2017 at 11:31:59PM +0300, Michael S. Tsirkin wrote:
>>> On Wed, Jul 12, 2017 at 05:15:50PM -0300, Eduardo Habkost wrote:
>>>> On Wed, Jul 12, 2017 at 06:17:55PM +0300, Michael S. Tsirkin wrote:
>>>>> On Wed, Jul 12, 2017 at 11:51:21AM -0300, Eduardo Habkost wrote:
>>>>>> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
>>>>>>> We don't want to carry along old machine types forever. If we are able to
>>>>>>> remove the pc machines up to 0.13 one day for example, this would allow
>>>>>>> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
>>>>>>> BARs directly to low memory). Everything up to pc-1.2 is also known to
>>>>>>> have issues with migration.  So let's start with a deprecation message
>>>>>>> for the old machine types so that the (hopefully) few users of these old
>>>>>>> systems start switching over to newer machine types instead.
>>>>>>>
>>>>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>>>>
>>>>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>>>>>>
>>>>>> I suggest changing "-machine help" too.  Today it looks like this:
>>>>>>
>>>>>>   Supported machines are:
>>>>>>   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
>>>>>>   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
>>>>>>   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-1.3               Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-1.2               Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-1.1               Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-1.0               Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-0.15              Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-0.14              Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-0.13              Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-0.12              Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-0.11              Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-0.10              Standard PC (i440FX + PIIX, 1996)
>>>>>>   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
>>>>>>   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
>>>>>>   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
>>>>>>   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
>>>>>>   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
>>>>>>   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
>>>>>>   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
>>>>>>   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
>>>>>>   isapc                ISA-only PC
>>>>>>   none                 empty machine
>>>>>
>>>>> Any chance we can sort them reasonably too?
>>>>
>>>> If we use strverscmp(), it will be sorted in a more reasonable
>>>> way.  We could copy the gnulib version on systems without glibc.
>>>> Life is too short for writing configure checks by hand, though; I
>>>> will add this to the end of my wish-todo list.  If somebody wants
>>>> to volunteer, be my guest.
>>>>
>>>> I'm CCing Eric in case he has suggestions that would help import
>>>> the gnulib module in an easy way.
>>>>
>>>> -- 
>>>> Eduardo
>>>
>>> As we never have leading zeroes, and input comes from QEMU so
>>> it's safe, it's probably easier to just open-code it:
>>>
>>> /* compare string numerically: shorter strings give smaller numbers */
>>> int mstcmp(const char *s1, const char *s2)
>>> {
>>> 	int l1, l2;
>>>
>>> 	l1 = strlen(s1);
>>> 	l2 = strlen(s2);
>>> 	return l1 == l2 ? strcmp(s1, s2) : l1 - l2;
>>> }
>>>
>>
>> This doesn't work because strlen("pc-0.10") > strlen("pc-1.0").
> 
> Oh right. So you need to find dots and split at these points.
> Something like the below? Completely untested.
> 
> int mstcmp(const char *s1, const char *s2)
> {
> 	const char *e1, *e2;
>  	int l1, l2, c;
> 
> 	do {
> 		e1 = strchr(s1, '.');
> 		e2 = strchr(s2, '.');
> 
> 		l1 = e1 ? e1 - s1 + 1 : strlen(s1);
> 		l2 = e2 ? e2 - s2 + 1 : strlen(s2);
> 
> 		/* compare numerically: shorter strings give smaller numbers */
> 		if (l1 != l2) {
> 			break;
> 		}
> 		c = strncmp(s1, s2, l1);
> 		if (c) {
> 			return c;
> 		}
> 		s1 += l1;
> 		s2 += l1;
> 	} while (l1);
> 
> 	return l1 - l2;
> }

QEMU already has machine type sorting code:

  1  2709f263952b well-defined listing order for machine types
  2  562542b6aee2 i386/pc: add piix and q35 machtypes to sorting
                  families for -M \?

I guess it should be possible to refine machine_class_cmp() in "vl.c",
so that some numeric sorting is applied to machine types in the same
"family".

Thanks
Laszlo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Laszlo Ersek]

On 07/12/17 10:22, Thomas Huth wrote:
> We don't want to carry along old machine types forever. If we are able to
> remove the pc machines up to 0.13 one day for example, this would allow
> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> BARs directly to low memory). Everything up to pc-1.2 is also known to
> have issues with migration.  So let's start with a deprecation message
> for the old machine types so that the (hopefully) few users of these old
> systems start switching over to newer machine types instead.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  Note: Even if we mark all these old machines as deprecated, this ofcourse
>  doesn't mean that we also have to remove them all at once later when we
>  decide to finally really remove some. We could then also start by removing
>  0.10 and 0.11 only, for example (since there should really be no users left
>  for these), or only up to 0.13 (to be able to kill rombar=0).

On a tangent: "rombar=0" shouldn't be killed before the libvirt domain
XML regains the ability to say, "don't load any oprom for this device".
Please see <https://bugzilla.redhat.com/show_bug.cgi?id=1425058>.

(Please note that it is not lost on me that rombar=0 is a poor
substitute for romfile='', but currently rombar=0 is the only fallback
through libvirt. See the BZ pls.)

Thanks
Laszlo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Michael S. Tsirkin]

On Thu, Jul 13, 2017 at 02:23:39AM +0200, Laszlo Ersek wrote:
> On 07/13/17 00:27, Michael S. Tsirkin wrote:
> > On Wed, Jul 12, 2017 at 05:56:46PM -0300, Eduardo Habkost wrote:
> >> On Wed, Jul 12, 2017 at 11:31:59PM +0300, Michael S. Tsirkin wrote:
> >>> On Wed, Jul 12, 2017 at 05:15:50PM -0300, Eduardo Habkost wrote:
> >>>> On Wed, Jul 12, 2017 at 06:17:55PM +0300, Michael S. Tsirkin wrote:
> >>>>> On Wed, Jul 12, 2017 at 11:51:21AM -0300, Eduardo Habkost wrote:
> >>>>>> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> >>>>>>> We don't want to carry along old machine types forever. If we are able to
> >>>>>>> remove the pc machines up to 0.13 one day for example, this would allow
> >>>>>>> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> >>>>>>> BARs directly to low memory). Everything up to pc-1.2 is also known to
> >>>>>>> have issues with migration.  So let's start with a deprecation message
> >>>>>>> for the old machine types so that the (hopefully) few users of these old
> >>>>>>> systems start switching over to newer machine types instead.
> >>>>>>>
> >>>>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
> >>>>>>
> >>>>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> >>>>>>
> >>>>>> I suggest changing "-machine help" too.  Today it looks like this:
> >>>>>>
> >>>>>>   Supported machines are:
> >>>>>>   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
> >>>>>>   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
> >>>>>>   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.3               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.2               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.1               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.0               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.15              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.14              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.13              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.12              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.11              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.10              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
> >>>>>>   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
> >>>>>>   isapc                ISA-only PC
> >>>>>>   none                 empty machine
> >>>>>
> >>>>> Any chance we can sort them reasonably too?
> >>>>
> >>>> If we use strverscmp(), it will be sorted in a more reasonable
> >>>> way.  We could copy the gnulib version on systems without glibc.
> >>>> Life is too short for writing configure checks by hand, though; I
> >>>> will add this to the end of my wish-todo list.  If somebody wants
> >>>> to volunteer, be my guest.
> >>>>
> >>>> I'm CCing Eric in case he has suggestions that would help import
> >>>> the gnulib module in an easy way.
> >>>>
> >>>> -- 
> >>>> Eduardo
> >>>
> >>> As we never have leading zeroes, and input comes from QEMU so
> >>> it's safe, it's probably easier to just open-code it:
> >>>
> >>> /* compare string numerically: shorter strings give smaller numbers */
> >>> int mstcmp(const char *s1, const char *s2)
> >>> {
> >>> 	int l1, l2;
> >>>
> >>> 	l1 = strlen(s1);
> >>> 	l2 = strlen(s2);
> >>> 	return l1 == l2 ? strcmp(s1, s2) : l1 - l2;
> >>> }
> >>>
> >>
> >> This doesn't work because strlen("pc-0.10") > strlen("pc-1.0").
> > 
> > Oh right. So you need to find dots and split at these points.
> > Something like the below? Completely untested.
> > 
> > int mstcmp(const char *s1, const char *s2)
> > {
> > 	const char *e1, *e2;
> >  	int l1, l2, c;
> > 
> > 	do {
> > 		e1 = strchr(s1, '.');
> > 		e2 = strchr(s2, '.');
> > 
> > 		l1 = e1 ? e1 - s1 + 1 : strlen(s1);
> > 		l2 = e2 ? e2 - s2 + 1 : strlen(s2);
> > 
> > 		/* compare numerically: shorter strings give smaller numbers */
> > 		if (l1 != l2) {
> > 			break;
> > 		}
> > 		c = strncmp(s1, s2, l1);
> > 		if (c) {
> > 			return c;
> > 		}
> > 		s1 += l1;
> > 		s2 += l1;
> > 	} while (l1);
> > 
> > 	return l1 - l2;
> > }
> 
> QEMU already has machine type sorting code:
> 
>   1  2709f263952b well-defined listing order for machine types
>   2  562542b6aee2 i386/pc: add piix and q35 machtypes to sorting
>                   families for -M \?
> 
> I guess it should be possible to refine machine_class_cmp() in "vl.c",
> so that some numeric sorting is applied to machine types in the same
> "family".
> 
> Thanks
> Laszlo

Exactly.

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Michael S. Tsirkin]

On Thu, Jul 13, 2017 at 02:30:06AM +0200, Laszlo Ersek wrote:
> On 07/12/17 10:22, Thomas Huth wrote:
> > We don't want to carry along old machine types forever. If we are able to
> > remove the pc machines up to 0.13 one day for example, this would allow
> > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> > BARs directly to low memory). Everything up to pc-1.2 is also known to
> > have issues with migration.  So let's start with a deprecation message
> > for the old machine types so that the (hopefully) few users of these old
> > systems start switching over to newer machine types instead.
> > 
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > ---
> >  Note: Even if we mark all these old machines as deprecated, this ofcourse
> >  doesn't mean that we also have to remove them all at once later when we
> >  decide to finally really remove some. We could then also start by removing
> >  0.10 and 0.11 only, for example (since there should really be no users left
> >  for these), or only up to 0.13 (to be able to kill rombar=0).
> 
> On a tangent: "rombar=0" shouldn't be killed before the libvirt domain
> XML regains the ability to say, "don't load any oprom for this device".
> Please see <https://bugzilla.redhat.com/show_bug.cgi?id=1425058>.
> 
> (Please note that it is not lost on me that rombar=0 is a poor
> substitute for romfile='', but currently rombar=0 is the only fallback
> through libvirt. See the BZ pls.)
> 
> Thanks
> Laszlo

rombar=0 would start meaning "no ROM", not "no BAR but still add a
rom".

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Michael S. Tsirkin]

On Thu, Jul 13, 2017 at 02:23:39AM +0200, Laszlo Ersek wrote:
> On 07/13/17 00:27, Michael S. Tsirkin wrote:
> > On Wed, Jul 12, 2017 at 05:56:46PM -0300, Eduardo Habkost wrote:
> >> On Wed, Jul 12, 2017 at 11:31:59PM +0300, Michael S. Tsirkin wrote:
> >>> On Wed, Jul 12, 2017 at 05:15:50PM -0300, Eduardo Habkost wrote:
> >>>> On Wed, Jul 12, 2017 at 06:17:55PM +0300, Michael S. Tsirkin wrote:
> >>>>> On Wed, Jul 12, 2017 at 11:51:21AM -0300, Eduardo Habkost wrote:
> >>>>>> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> >>>>>>> We don't want to carry along old machine types forever. If we are able to
> >>>>>>> remove the pc machines up to 0.13 one day for example, this would allow
> >>>>>>> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> >>>>>>> BARs directly to low memory). Everything up to pc-1.2 is also known to
> >>>>>>> have issues with migration.  So let's start with a deprecation message
> >>>>>>> for the old machine types so that the (hopefully) few users of these old
> >>>>>>> systems start switching over to newer machine types instead.
> >>>>>>>
> >>>>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
> >>>>>>
> >>>>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> >>>>>>
> >>>>>> I suggest changing "-machine help" too.  Today it looks like this:
> >>>>>>
> >>>>>>   Supported machines are:
> >>>>>>   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
> >>>>>>   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
> >>>>>>   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.3               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.2               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.1               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.0               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.15              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.14              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.13              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.12              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.11              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.10              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
> >>>>>>   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
> >>>>>>   isapc                ISA-only PC
> >>>>>>   none                 empty machine
> >>>>>
> >>>>> Any chance we can sort them reasonably too?
> >>>>
> >>>> If we use strverscmp(), it will be sorted in a more reasonable
> >>>> way.  We could copy the gnulib version on systems without glibc.
> >>>> Life is too short for writing configure checks by hand, though; I
> >>>> will add this to the end of my wish-todo list.  If somebody wants
> >>>> to volunteer, be my guest.
> >>>>
> >>>> I'm CCing Eric in case he has suggestions that would help import
> >>>> the gnulib module in an easy way.
> >>>>
> >>>> -- 
> >>>> Eduardo
> >>>
> >>> As we never have leading zeroes, and input comes from QEMU so
> >>> it's safe, it's probably easier to just open-code it:
> >>>
> >>> /* compare string numerically: shorter strings give smaller numbers */
> >>> int mstcmp(const char *s1, const char *s2)
> >>> {
> >>> 	int l1, l2;
> >>>
> >>> 	l1 = strlen(s1);
> >>> 	l2 = strlen(s2);
> >>> 	return l1 == l2 ? strcmp(s1, s2) : l1 - l2;
> >>> }
> >>>
> >>
> >> This doesn't work because strlen("pc-0.10") > strlen("pc-1.0").
> > 
> > Oh right. So you need to find dots and split at these points.
> > Something like the below? Completely untested.
> > 
> > int mstcmp(const char *s1, const char *s2)
> > {
> > 	const char *e1, *e2;
> >  	int l1, l2, c;
> > 
> > 	do {
> > 		e1 = strchr(s1, '.');
> > 		e2 = strchr(s2, '.');
> > 
> > 		l1 = e1 ? e1 - s1 + 1 : strlen(s1);
> > 		l2 = e2 ? e2 - s2 + 1 : strlen(s2);
> > 
> > 		/* compare numerically: shorter strings give smaller numbers */
> > 		if (l1 != l2) {
> > 			break;
> > 		}
> > 		c = strncmp(s1, s2, l1);
> > 		if (c) {
> > 			return c;
> > 		}
> > 		s1 += l1;
> > 		s2 += l1;
> > 	} while (l1);
> > 
> > 	return l1 - l2;
> > }
> 
> QEMU already has machine type sorting code:
> 
>   1  2709f263952b well-defined listing order for machine types
>   2  562542b6aee2 i386/pc: add piix and q35 machtypes to sorting
>                   families for -M \?
> 
> I guess it should be possible to refine machine_class_cmp() in "vl.c",
> so that some numeric sorting is applied to machine types in the same
> "family".
> 
> Thanks
> Laszlo

Exactly.

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Michael S. Tsirkin]

On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> We don't want to carry along old machine types forever. If we are able to
> remove the pc machines up to 0.13 one day for example, this would allow
> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> BARs directly to low memory). Everything up to pc-1.2 is also known to
> have issues with migration.  So let's start with a deprecation message
> for the old machine types so that the (hopefully) few users of these old
> systems start switching over to newer machine types instead.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  Note: Even if we mark all these old machines as deprecated, this ofcourse
>  doesn't mean that we also have to remove them all at once later when we
>  decide to finally really remove some. We could then also start by removing
>  0.10 and 0.11 only, for example (since there should really be no users left
>  for these), or only up to 0.13 (to be able to kill rombar=0).

So I generally think the main issue is that machine types are conflating
two things. One is saying "I want to be able to migrate from/to QEMU X".
Another is saying "I want to look to guests as if I am QEMU X
but I restart gurst on the new QEMU".

First is generally a superset of the second, but only a subset of
users needs the first. And while there's a very good chance we
are actually pretty close to supporting the second even for very
old machine types, I doubt we are actually able to migrate to/from
these old QEMU versions since it is so hard to test.

So IMHO, a more significant step with a long term impact would be to
support splitting these things up.



>  v3:
>  - Use a more generic approach by introducing a "deprecation_msg" in the
>    MachineClass instead.
> 
>  v2:
>  - Deprecate machines up to pc-1.2
> 
>  hw/i386/pc_piix.c   | 1 +
>  include/hw/boards.h | 1 +
>  vl.c                | 4 ++++
>  3 files changed, 6 insertions(+)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 22dbef6..8e70308 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -707,6 +707,7 @@ static void pc_i440fx_1_2_machine_options(MachineClass *m)
>  {
>      pc_i440fx_1_3_machine_options(m);
>      m->hw_version = "1.2.0";
> +    m->deprecation_msg = "Please use a newer machine type instead.";
>      SET_MACHINE_COMPAT(m, PC_COMPAT_1_2);
>  }
>  
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 76ce021..42a0264 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -112,6 +112,7 @@ struct MachineClass {
>      char *name;
>      const char *alias;
>      const char *desc;
> +    const char *deprecation_msg;
>  
>      void (*init)(MachineState *state);
>      void (*reset)(void);
> diff --git a/vl.c b/vl.c
> index f7560de..0058d41 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4115,6 +4115,10 @@ int main(int argc, char **argv, char **envp)
>      replay_configure(icount_opts);
>  
>      machine_class = select_machine();
> +    if (machine_class->deprecation_msg) {
> +        error_report("Machine type '%s' is deprecated. %s",
> +                     machine_class->name, machine_class->deprecation_msg);
> +    }
>  
>      set_memory_options(&ram_slots, &maxram_size, machine_class);
>  
> -- 
> 1.8.3.1

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Laszlo Ersek]

On 07/13/17 02:47, Michael S. Tsirkin wrote:
> On Thu, Jul 13, 2017 at 02:30:06AM +0200, Laszlo Ersek wrote:
>> On 07/12/17 10:22, Thomas Huth wrote:
>>> We don't want to carry along old machine types forever. If we are able to
>>> remove the pc machines up to 0.13 one day for example, this would allow
>>> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
>>> BARs directly to low memory). Everything up to pc-1.2 is also known to
>>> have issues with migration.  So let's start with a deprecation message
>>> for the old machine types so that the (hopefully) few users of these old
>>> systems start switching over to newer machine types instead.
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>>  Note: Even if we mark all these old machines as deprecated, this ofcourse
>>>  doesn't mean that we also have to remove them all at once later when we
>>>  decide to finally really remove some. We could then also start by removing
>>>  0.10 and 0.11 only, for example (since there should really be no users left
>>>  for these), or only up to 0.13 (to be able to kill rombar=0).
>>
>> On a tangent: "rombar=0" shouldn't be killed before the libvirt domain
>> XML regains the ability to say, "don't load any oprom for this device".
>> Please see <https://bugzilla.redhat.com/show_bug.cgi?id=1425058>.
>>
>> (Please note that it is not lost on me that rombar=0 is a poor
>> substitute for romfile='', but currently rombar=0 is the only fallback
>> through libvirt. See the BZ pls.)
>>
>> Thanks
>> Laszlo
> 
> rombar=0 would start meaning "no ROM", not "no BAR but still add a
> rom".
> 

Ah! In that case, it would actually obviate RHBZ#1425058.

Thanks,
Laszlo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Eduardo Habkost]

On Thu, Jul 13, 2017 at 02:23:39AM +0200, Laszlo Ersek wrote:
> On 07/13/17 00:27, Michael S. Tsirkin wrote:
> > On Wed, Jul 12, 2017 at 05:56:46PM -0300, Eduardo Habkost wrote:
> >> On Wed, Jul 12, 2017 at 11:31:59PM +0300, Michael S. Tsirkin wrote:
> >>> On Wed, Jul 12, 2017 at 05:15:50PM -0300, Eduardo Habkost wrote:
> >>>> On Wed, Jul 12, 2017 at 06:17:55PM +0300, Michael S. Tsirkin wrote:
> >>>>> On Wed, Jul 12, 2017 at 11:51:21AM -0300, Eduardo Habkost wrote:
> >>>>>> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> >>>>>>> We don't want to carry along old machine types forever. If we are able to
> >>>>>>> remove the pc machines up to 0.13 one day for example, this would allow
> >>>>>>> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> >>>>>>> BARs directly to low memory). Everything up to pc-1.2 is also known to
> >>>>>>> have issues with migration.  So let's start with a deprecation message
> >>>>>>> for the old machine types so that the (hopefully) few users of these old
> >>>>>>> systems start switching over to newer machine types instead.
> >>>>>>>
> >>>>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
> >>>>>>
> >>>>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> >>>>>>
> >>>>>> I suggest changing "-machine help" too.  Today it looks like this:
> >>>>>>
> >>>>>>   Supported machines are:
> >>>>>>   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
> >>>>>>   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
> >>>>>>   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.3               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.2               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.1               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-1.0               Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.15              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.14              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.13              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.12              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.11              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-0.10              Standard PC (i440FX + PIIX, 1996)
> >>>>>>   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
> >>>>>>   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
> >>>>>>   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
> >>>>>>   isapc                ISA-only PC
> >>>>>>   none                 empty machine
> >>>>>
> >>>>> Any chance we can sort them reasonably too?
> >>>>
> >>>> If we use strverscmp(), it will be sorted in a more reasonable
> >>>> way.  We could copy the gnulib version on systems without glibc.
> >>>> Life is too short for writing configure checks by hand, though; I
> >>>> will add this to the end of my wish-todo list.  If somebody wants
> >>>> to volunteer, be my guest.
> >>>>
> >>>> I'm CCing Eric in case he has suggestions that would help import
> >>>> the gnulib module in an easy way.
> >>>>
> >>>> -- 
> >>>> Eduardo
> >>>
> >>> As we never have leading zeroes, and input comes from QEMU so
> >>> it's safe, it's probably easier to just open-code it:
> >>>
> >>> /* compare string numerically: shorter strings give smaller numbers */
> >>> int mstcmp(const char *s1, const char *s2)
> >>> {
> >>> 	int l1, l2;
> >>>
> >>> 	l1 = strlen(s1);
> >>> 	l2 = strlen(s2);
> >>> 	return l1 == l2 ? strcmp(s1, s2) : l1 - l2;
> >>> }
> >>>
> >>
> >> This doesn't work because strlen("pc-0.10") > strlen("pc-1.0").
> > 
> > Oh right. So you need to find dots and split at these points.
> > Something like the below? Completely untested.
> > 
> > int mstcmp(const char *s1, const char *s2)
> > {
> > 	const char *e1, *e2;
> >  	int l1, l2, c;
> > 
> > 	do {
> > 		e1 = strchr(s1, '.');
> > 		e2 = strchr(s2, '.');
> > 
> > 		l1 = e1 ? e1 - s1 + 1 : strlen(s1);
> > 		l2 = e2 ? e2 - s2 + 1 : strlen(s2);
> > 
> > 		/* compare numerically: shorter strings give smaller numbers */
> > 		if (l1 != l2) {
> > 			break;
> > 		}
> > 		c = strncmp(s1, s2, l1);
> > 		if (c) {
> > 			return c;
> > 		}
> > 		s1 += l1;
> > 		s2 += l1;
> > 	} while (l1);
> > 
> > 	return l1 - l2;
> > }

I believe copying strverscmp() from gnulib as-is is better than
reimplementing a subset of it.

> 
> QEMU already has machine type sorting code:
> 
>   1  2709f263952b well-defined listing order for machine types
>   2  562542b6aee2 i386/pc: add piix and q35 machtypes to sorting
>                   families for -M \?
> 
> I guess it should be possible to refine machine_class_cmp() in "vl.c",
> so that some numeric sorting is applied to machine types in the same
> "family".

Yes.  My suggestion is to use strverscmp() inside
machine_class_cmp().

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Eduardo Habkost]

On Thu, Jul 13, 2017 at 04:00:00AM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> > We don't want to carry along old machine types forever. If we are able to
> > remove the pc machines up to 0.13 one day for example, this would allow
> > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> > BARs directly to low memory). Everything up to pc-1.2 is also known to
> > have issues with migration.  So let's start with a deprecation message
> > for the old machine types so that the (hopefully) few users of these old
> > systems start switching over to newer machine types instead.
> > 
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > ---
> >  Note: Even if we mark all these old machines as deprecated, this ofcourse
> >  doesn't mean that we also have to remove them all at once later when we
> >  decide to finally really remove some. We could then also start by removing
> >  0.10 and 0.11 only, for example (since there should really be no users left
> >  for these), or only up to 0.13 (to be able to kill rombar=0).
> 
> So I generally think the main issue is that machine types are conflating
> two things. One is saying "I want to be able to migrate from/to QEMU X".
> Another is saying "I want to look to guests as if I am QEMU X
> but I restart gurst on the new QEMU".
> 
> First is generally a superset of the second, but only a subset of
> users needs the first. And while there's a very good chance we
> are actually pretty close to supporting the second even for very
> old machine types, I doubt we are actually able to migrate to/from
> these old QEMU versions since it is so hard to test.
> 
> So IMHO, a more significant step with a long term impact would be to
> support splitting these things up.

I agree they are different things, but do we really have
volunteers willing to maintain a machine-type just because of the
latter?  Setting the same deprecation policy for the two features
sounds simpler to me.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

On 07/12/2017 03:15 PM, Eduardo Habkost wrote:

> 
> If we use strverscmp(), it will be sorted in a more reasonable
> way.  We could copy the gnulib version on systems without glibc.
> Life is too short for writing configure checks by hand, though; I
> will add this to the end of my wish-todo list.  If somebody wants
> to volunteer, be my guest.
> 
> I'm CCing Eric in case he has suggestions that would help import
> the gnulib module in an easy way.

We don't use autoconf, so we can't directly use gnulib. Copying the
files and making sure we provide the configure tests those files depend
on (or tweaking the files to simplify to our build system, where we
don't have to be quite as portable as gnulib tries to be) is going to be
a manual process. But at least the license is compatible (LGPLv2+), and
I'll willingly review patches attempted along those lines.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Laszlo Ersek]

On 07/13/17 17:17, Eduardo Habkost wrote:
> On Thu, Jul 13, 2017 at 02:23:39AM +0200, Laszlo Ersek wrote:
>> On 07/13/17 00:27, Michael S. Tsirkin wrote:
>>> On Wed, Jul 12, 2017 at 05:56:46PM -0300, Eduardo Habkost wrote:
>>>> On Wed, Jul 12, 2017 at 11:31:59PM +0300, Michael S. Tsirkin wrote:
>>>>> On Wed, Jul 12, 2017 at 05:15:50PM -0300, Eduardo Habkost wrote:
>>>>>> On Wed, Jul 12, 2017 at 06:17:55PM +0300, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Jul 12, 2017 at 11:51:21AM -0300, Eduardo Habkost wrote:
>>>>>>>> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
>>>>>>>>> We don't want to carry along old machine types forever. If we are able to
>>>>>>>>> remove the pc machines up to 0.13 one day for example, this would allow
>>>>>>>>> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
>>>>>>>>> BARs directly to low memory). Everything up to pc-1.2 is also known to
>>>>>>>>> have issues with migration.  So let's start with a deprecation message
>>>>>>>>> for the old machine types so that the (hopefully) few users of these old
>>>>>>>>> systems start switching over to newer machine types instead.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>>>>>>
>>>>>>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>>>>>>>>
>>>>>>>> I suggest changing "-machine help" too.  Today it looks like this:
>>>>>>>>
>>>>>>>>   Supported machines are:
>>>>>>>>   pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.10)
>>>>>>>>   pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996) (default)
>>>>>>>>   pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-1.3               Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-1.2               Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-1.1               Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-1.0               Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-0.15              Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-0.14              Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-0.13              Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-0.12              Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-0.11              Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-0.10              Standard PC (i440FX + PIIX, 1996)
>>>>>>>>   pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
>>>>>>>>   pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
>>>>>>>>   pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
>>>>>>>>   pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
>>>>>>>>   pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
>>>>>>>>   pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
>>>>>>>>   q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.10)
>>>>>>>>   pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
>>>>>>>>   isapc                ISA-only PC
>>>>>>>>   none                 empty machine
>>>>>>>
>>>>>>> Any chance we can sort them reasonably too?
>>>>>>
>>>>>> If we use strverscmp(), it will be sorted in a more reasonable
>>>>>> way.  We could copy the gnulib version on systems without glibc.
>>>>>> Life is too short for writing configure checks by hand, though; I
>>>>>> will add this to the end of my wish-todo list.  If somebody wants
>>>>>> to volunteer, be my guest.
>>>>>>
>>>>>> I'm CCing Eric in case he has suggestions that would help import
>>>>>> the gnulib module in an easy way.
>>>>>>
>>>>>> -- 
>>>>>> Eduardo
>>>>>
>>>>> As we never have leading zeroes, and input comes from QEMU so
>>>>> it's safe, it's probably easier to just open-code it:
>>>>>
>>>>> /* compare string numerically: shorter strings give smaller numbers */
>>>>> int mstcmp(const char *s1, const char *s2)
>>>>> {
>>>>> 	int l1, l2;
>>>>>
>>>>> 	l1 = strlen(s1);
>>>>> 	l2 = strlen(s2);
>>>>> 	return l1 == l2 ? strcmp(s1, s2) : l1 - l2;
>>>>> }
>>>>>
>>>>
>>>> This doesn't work because strlen("pc-0.10") > strlen("pc-1.0").
>>>
>>> Oh right. So you need to find dots and split at these points.
>>> Something like the below? Completely untested.
>>>
>>> int mstcmp(const char *s1, const char *s2)
>>> {
>>> 	const char *e1, *e2;
>>>  	int l1, l2, c;
>>>
>>> 	do {
>>> 		e1 = strchr(s1, '.');
>>> 		e2 = strchr(s2, '.');
>>>
>>> 		l1 = e1 ? e1 - s1 + 1 : strlen(s1);
>>> 		l2 = e2 ? e2 - s2 + 1 : strlen(s2);
>>>
>>> 		/* compare numerically: shorter strings give smaller numbers */
>>> 		if (l1 != l2) {
>>> 			break;
>>> 		}
>>> 		c = strncmp(s1, s2, l1);
>>> 		if (c) {
>>> 			return c;
>>> 		}
>>> 		s1 += l1;
>>> 		s2 += l1;
>>> 	} while (l1);
>>>
>>> 	return l1 - l2;
>>> }
> 
> I believe copying strverscmp() from gnulib as-is is better than
> reimplementing a subset of it.
> 
>>
>> QEMU already has machine type sorting code:
>>
>>   1  2709f263952b well-defined listing order for machine types
>>   2  562542b6aee2 i386/pc: add piix and q35 machtypes to sorting
>>                   families for -M \?
>>
>> I guess it should be possible to refine machine_class_cmp() in "vl.c",
>> so that some numeric sorting is applied to machine types in the same
>> "family".
> 
> Yes.  My suggestion is to use strverscmp() inside
> machine_class_cmp().
> 

Works for me!
Thanks
Laszlo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Michael S. Tsirkin]

On Thu, Jul 13, 2017 at 12:17:40PM -0300, Eduardo Habkost wrote:
> > > Oh right. So you need to find dots and split at these points.
> > > Something like the below? Completely untested.
> > > 
> > > int mstcmp(const char *s1, const char *s2)
> > > {
> > > 	const char *e1, *e2;
> > >  	int l1, l2, c;
> > > 
> > > 	do {
> > > 		e1 = strchr(s1, '.');
> > > 		e2 = strchr(s2, '.');
> > > 
> > > 		l1 = e1 ? e1 - s1 + 1 : strlen(s1);
> > > 		l2 = e2 ? e2 - s2 + 1 : strlen(s2);
> > > 
> > > 		/* compare numerically: shorter strings give smaller numbers */
> > > 		if (l1 != l2) {
> > > 			break;
> > > 		}
> > > 		c = strncmp(s1, s2, l1);
> > > 		if (c) {
> > > 			return c;
> > > 		}
> > > 		s1 += l1;
> > > 		s2 += l1;
> > > 	} while (l1);
> > > 
> > > 	return l1 - l2;
> > > }
> 
> I believe copying strverscmp() from gnulib as-is is better than
> reimplementing a subset of it.

I would then probably copy it unconditionally.

> 
> -- 
> Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Michael S. Tsirkin]

On Thu, Jul 13, 2017 at 12:20:10PM -0300, Eduardo Habkost wrote:
> On Thu, Jul 13, 2017 at 04:00:00AM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> > > We don't want to carry along old machine types forever. If we are able to
> > > remove the pc machines up to 0.13 one day for example, this would allow
> > > us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> > > BARs directly to low memory). Everything up to pc-1.2 is also known to
> > > have issues with migration.  So let's start with a deprecation message
> > > for the old machine types so that the (hopefully) few users of these old
> > > systems start switching over to newer machine types instead.
> > > 
> > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > ---
> > >  Note: Even if we mark all these old machines as deprecated, this ofcourse
> > >  doesn't mean that we also have to remove them all at once later when we
> > >  decide to finally really remove some. We could then also start by removing
> > >  0.10 and 0.11 only, for example (since there should really be no users left
> > >  for these), or only up to 0.13 (to be able to kill rombar=0).
> > 
> > So I generally think the main issue is that machine types are conflating
> > two things. One is saying "I want to be able to migrate from/to QEMU X".
> > Another is saying "I want to look to guests as if I am QEMU X
> > but I restart gurst on the new QEMU".
> > 
> > First is generally a superset of the second, but only a subset of
> > users needs the first. And while there's a very good chance we
> > are actually pretty close to supporting the second even for very
> > old machine types, I doubt we are actually able to migrate to/from
> > these old QEMU versions since it is so hard to test.
> > 
> > So IMHO, a more significant step with a long term impact would be to
> > support splitting these things up.
> 
> I agree they are different things, but do we really have
> volunteers willing to maintain a machine-type just because of the
> latter?  Setting the same deprecation policy for the two features
> sounds simpler to me.

Removing the former might kind of work just this once on the assumption
that we did not have real users back then, but fundamentally users have
no safe way to upgrade machine types right now. It's stored in the
machine XML at install time and that's it, and reinstalling guests
is very painful.

So starting with version X when we did have real users, we really have
to maintain the latter literally forever, volunteers or not.  Former is
another question, it's a simpler work-around to restart guest, so we can
limit what we support.

> -- 
> Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Michael S. Tsirkin]

On Wed, Jul 12, 2017 at 05:29:01PM +0100, Daniel P. Berrange wrote:
> Yep, I'm amenable to that POV too. It is entirely valid to say that if
> downstream distros need to care about such ancient back-compat, then they
> will just have to do the extra work to use git history to undelete any bits
> they need that upstream has discarded.

Unfortunately people seem to conflate compatibility question of live
migration and of booting images.

Live migration is a complex topic, and you always have a work
around of restarting the VM to upgrade if it does not work.

But I don't think we can stop supporting booting old images, ever, for
all versions that have a decent number of users, until someone develops
a tool to upgrade machine type in XML painlessly and safely.

If we can guarantee that changing pc-0.10 to pc-1.13 will keep booting,
then we should just alias one to another so people can stil start their
VMs. If we can't then we really can't drop old machine types from
booting point of view.

-- 
MST

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Thomas Huth]

On 14.07.2017 01:04, Michael S. Tsirkin wrote:
> On Thu, Jul 13, 2017 at 12:20:10PM -0300, Eduardo Habkost wrote:
>> On Thu, Jul 13, 2017 at 04:00:00AM +0300, Michael S. Tsirkin wrote:
>>> On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
>>>> We don't want to carry along old machine types forever. If we are able to
>>>> remove the pc machines up to 0.13 one day for example, this would allow
>>>> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
>>>> BARs directly to low memory). Everything up to pc-1.2 is also known to
>>>> have issues with migration.  So let's start with a deprecation message
>>>> for the old machine types so that the (hopefully) few users of these old
>>>> systems start switching over to newer machine types instead.
>>>>
>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>> ---
>>>>  Note: Even if we mark all these old machines as deprecated, this ofcourse
>>>>  doesn't mean that we also have to remove them all at once later when we
>>>>  decide to finally really remove some. We could then also start by removing
>>>>  0.10 and 0.11 only, for example (since there should really be no users left
>>>>  for these), or only up to 0.13 (to be able to kill rombar=0).
>>>
>>> So I generally think the main issue is that machine types are conflating
>>> two things. One is saying "I want to be able to migrate from/to QEMU X".
>>> Another is saying "I want to look to guests as if I am QEMU X
>>> but I restart gurst on the new QEMU".
>>>
>>> First is generally a superset of the second, but only a subset of
>>> users needs the first. And while there's a very good chance we
>>> are actually pretty close to supporting the second even for very
>>> old machine types, I doubt we are actually able to migrate to/from
>>> these old QEMU versions since it is so hard to test.
>>>
>>> So IMHO, a more significant step with a long term impact would be to
>>> support splitting these things up.
>>
>> I agree they are different things, but do we really have
>> volunteers willing to maintain a machine-type just because of the
>> latter?  Setting the same deprecation policy for the two features
>> sounds simpler to me.
> 
> Removing the former might kind of work just this once on the assumption
> that we did not have real users back then, but fundamentally users have
> no safe way to upgrade machine types right now. It's stored in the
> machine XML at install time and that's it, and reinstalling guests
> is very painful.
> 
> So starting with version X when we did have real users, we really have
> to maintain the latter literally forever, volunteers or not.

Do we? If someone has a VM that depends on a veeery old machine type
(and it can not be started with a newer machine type - which is quite
unlikely since they are normally very similar), I guess they could also
simply use older versions of QEMU for that VM instead.

 Thomas

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Gerd Hoffmann]

  Hi,

> Removing the former might kind of work just this once on the
> assumption
> that we did not have real users back then, but fundamentally users
> have
> no safe way to upgrade machine types right now. It's stored in the
> machine XML at install time and that's it, and reinstalling guests
> is very painful.

You can easily change it using "virsh edit $domain", and improving
virt-manager to offer some UI for that should be possible too.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Eduardo Habkost]

On Fri, Jul 14, 2017 at 01:41:58AM +0300, Michael S. Tsirkin wrote:
> On Thu, Jul 13, 2017 at 12:17:40PM -0300, Eduardo Habkost wrote:
> > > > Oh right. So you need to find dots and split at these points.
> > > > Something like the below? Completely untested.
> > > > 
> > > > int mstcmp(const char *s1, const char *s2)
> > > > {
> > > > 	const char *e1, *e2;
> > > >  	int l1, l2, c;
> > > > 
> > > > 	do {
> > > > 		e1 = strchr(s1, '.');
> > > > 		e2 = strchr(s2, '.');
> > > > 
> > > > 		l1 = e1 ? e1 - s1 + 1 : strlen(s1);
> > > > 		l2 = e2 ? e2 - s2 + 1 : strlen(s2);
> > > > 
> > > > 		/* compare numerically: shorter strings give smaller numbers */
> > > > 		if (l1 != l2) {
> > > > 			break;
> > > > 		}
> > > > 		c = strncmp(s1, s2, l1);
> > > > 		if (c) {
> > > > 			return c;
> > > > 		}
> > > > 		s1 += l1;
> > > > 		s2 += l1;
> > > > 	} while (l1);
> > > > 
> > > > 	return l1 - l2;
> > > > }
> > 
> > I believe copying strverscmp() from gnulib as-is is better than
> > reimplementing a subset of it.
> 
> I would then probably copy it unconditionally.

That's probably what I will do.  Saving a few bytes in the QEMU
binary is probably not worth the extra ./configure cruft.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2

[Eduardo Habkost]

On Fri, Jul 14, 2017 at 02:14:33AM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 12, 2017 at 05:29:01PM +0100, Daniel P. Berrange wrote:
> > Yep, I'm amenable to that POV too. It is entirely valid to say that if
> > downstream distros need to care about such ancient back-compat, then they
> > will just have to do the extra work to use git history to undelete any bits
> > they need that upstream has discarded.
> 
> Unfortunately people seem to conflate compatibility question of live
> migration and of booting images.
> 
> Live migration is a complex topic, and you always have a work
> around of restarting the VM to upgrade if it does not work.
> 
> But I don't think we can stop supporting booting old images, ever, for
> all versions that have a decent number of users, until someone develops
> a tool to upgrade machine type in XML painlessly and safely.
> 

I don't agree with this part.  It's perfectly valid to remove a
feature from a software component if nobody is willing to
maintain it.

> If we can guarantee that changing pc-0.10 to pc-1.13 will keep booting,
> then we should just alias one to another so people can stil start their
> VMs. If we can't then we really can't drop old machine types from
> booting point of view.

I don't think we can't guarantee that changing "pc-0.10" to
"pc-0.13" will keep working, just like we can't guarantee that
"pc-0.10" is still working in QEMU 2.9 the way it did in QEMU
0.10.

We try to not break stuff, but we can't really guarantee anything
on either case (keeping the old machine-types; making the old
machine-type names aliases; or deleting the old machine-types),
if we are not spending efforts testing that.  Keeping the old
machine-type names (either as real machines or as aliases) just
gives us the illusion that we didn't break anything.

-- 
Eduardo