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
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>
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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.
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
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 :|
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
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 :|
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
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 :|
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
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 :|
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
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
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
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
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
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".
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
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
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
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
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
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
© 2016 - 2024 Red Hat, Inc.