QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
* [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines
@ 2017-11-08  2:28 Philippe Mathieu-Daudé
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property Philippe Mathieu-Daudé
                   ` (7 more replies)
  0 siblings, 8 replies; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2017-11-08  2:28 UTC (permalink / raw)
  To: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Michael S. Tsirkin,
	Richard Henderson, Hervé Poussineau, David Gibson,
	Alexander Graf, Michael Roth
  Cc: Philippe Mathieu-Daudé, qemu-devel

Hi,

This series intends to provide a simple and common way to deprecate
machines between releases. It may be extended to deprecate devices.

I started with the machines list from:

  https://wiki.qemu.org/Features/LegacyRemoval#Deprecated_machines

Comment welcomed :)

Regards,

Phil.

Alistair Francis (1):
  hw/arm: deprecate the EP108 board

Philippe Mathieu-Daudé (5):
  machine: add a deprecated_reason property
  hw/arm: deprecate the Gumstix boards
  hw/ppc: deprecate the PReP machine
  hw/i386: deprecate the pc-0.10 and pc-0.11 machines
  hw/i386: deprecate the "isapc" machine

 include/hw/boards.h  | 1 +
 hw/arm/gumstix.c     | 2 ++
 hw/arm/xlnx-zcu102.c | 6 +++++-
 hw/i386/pc_piix.c    | 3 +++
 hw/ppc/prep.c        | 1 +
 vl.c                 | 7 +++++++
 6 files changed, 19 insertions(+), 1 deletion(-)

-- 
2.15.0

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property
  2017-11-08  2:28 [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Philippe Mathieu-Daudé
@ 2017-11-08  2:28 ` Philippe Mathieu-Daudé
  2017-11-08 10:23   ` Thomas Huth
  2017-11-08 20:29   ` Eduardo Habkost
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 2/6] hw/arm: deprecate the EP108 board Philippe Mathieu-Daudé
                   ` (6 subsequent siblings)
  7 siblings, 2 replies; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2017-11-08  2:28 UTC (permalink / raw)
  To: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Michael Roth
  Cc: Philippe Mathieu-Daudé, qemu-devel

If a machine has the deprecated_reason property set:
- it won't get listed anymore by the "-M help" command,
- a warning will be displayed if the machine is used.

Example:
  $ ppc-softmmu/qemu-system-ppc -M prep
  qemu-system-ppc: -M prep: warning: The PowerPC PREP platform machine is deprecated (Obsoleted by the "40p" machine)
  [machine starting ...]

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 include/hw/boards.h | 1 +
 vl.c                | 7 +++++++
 2 files changed, 8 insertions(+)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index 191a5b3cd8..4d5c180968 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -182,6 +182,7 @@ struct MachineClass {
     const char *default_boot_order;
     const char *default_display;
     GArray *compat_props;
+    const char *deprecated_reason;
     const char *hw_version;
     ram_addr_t default_ram_size;
     const char *default_cpu_type;
diff --git a/vl.c b/vl.c
index ec299099ff..9ed4648af2 100644
--- a/vl.c
+++ b/vl.c
@@ -2742,6 +2742,10 @@ static gint machine_class_cmp(gconstpointer a, gconstpointer b)
     }
     if (mc) {
         g_slist_free(machines);
+        if (mc->deprecated_reason) {
+            warn_report("The %s machine is deprecated (%s)",
+                        mc->desc, mc->deprecated_reason);
+        }
         return mc;
     }
     if (name && !is_help_option(name)) {
@@ -2752,6 +2756,9 @@ static gint machine_class_cmp(gconstpointer a, gconstpointer b)
         machines = g_slist_sort(machines, machine_class_cmp);
         for (el = machines; el; el = el->next) {
             MachineClass *mc = el->data;
+            if (mc->deprecated_reason) {
+                continue;
+            }
             if (mc->alias) {
                 printf("%-20s %s (alias of %s)\n", mc->alias, mc->desc, mc->name);
             }
-- 
2.15.0

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [Qemu-devel] [RFC PATCH 2/6] hw/arm: deprecate the EP108 board
  2017-11-08  2:28 [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Philippe Mathieu-Daudé
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property Philippe Mathieu-Daudé
@ 2017-11-08  2:28 ` Philippe Mathieu-Daudé
  2017-11-08  9:17   ` Daniel P. Berrange
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 3/6] hw/arm: deprecate the Gumstix boards Philippe Mathieu-Daudé
                   ` (5 subsequent siblings)
  7 siblings, 1 reply; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2017-11-08  2:28 UTC (permalink / raw)
  To: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Edgar E. Iglesias
  Cc: qemu-devel, qemu-arm, Philippe Mathieu-Daudé

From: Alistair Francis <alistair.francis@xilinx.com>

The EP108 was an early access development board that is no longer used.
Add an info message to convert any users to the ZCU102 instead. On QEMU
they are both identical.

Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/arm/xlnx-zcu102.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
index e2d15a1c9d..d42b6e3d3a 100644
--- a/hw/arm/xlnx-zcu102.c
+++ b/hw/arm/xlnx-zcu102.c
@@ -164,6 +164,8 @@ static void xlnx_ep108_init(MachineState *machine)
 {
     XlnxZCU102 *s = EP108_MACHINE(machine);
 
+    info_report("Please use the ZCU102 machine instead of this machine.");
+
     xlnx_zynqmp_init(s, machine);
 }
 
@@ -180,11 +182,13 @@ static void xlnx_ep108_machine_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
 
-    mc->desc = "Xilinx ZynqMP EP108 board (Deprecated, please use xlnx-zcu102)";
+    mc->desc = "Xilinx ZynqMP EP108 board";
     mc->init = xlnx_ep108_init;
     mc->block_default_type = IF_IDE;
     mc->units_per_default_bus = 1;
     mc->ignore_memory_transaction_failures = true;
+    mc->deprecated_reason =
+        "The ZCU102 machine has the same features supported";
 }
 
 static const TypeInfo xlnx_ep108_machine_init_typeinfo = {
-- 
2.15.0

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [Qemu-devel] [RFC PATCH 3/6] hw/arm: deprecate the Gumstix boards
  2017-11-08  2:28 [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Philippe Mathieu-Daudé
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property Philippe Mathieu-Daudé
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 2/6] hw/arm: deprecate the EP108 board Philippe Mathieu-Daudé
@ 2017-11-08  2:28 ` Philippe Mathieu-Daudé
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 4/6] hw/ppc: deprecate the PReP machine Philippe Mathieu-Daudé
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2017-11-08  2:28 UTC (permalink / raw)
  To: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum
  Cc: Philippe Mathieu-Daudé, qemu-devel, qemu-arm

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/arm/gumstix.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/arm/gumstix.c b/hw/arm/gumstix.c
index bba9e9f57a..160f7f089c 100644
--- a/hw/arm/gumstix.c
+++ b/hw/arm/gumstix.c
@@ -129,6 +129,7 @@ static void connex_class_init(ObjectClass *oc, void *data)
     mc->desc = "Gumstix Connex (PXA255)";
     mc->init = connex_init;
     mc->ignore_memory_transaction_failures = true;
+    mc->deprecated_reason = "Unmaintained";
 }
 
 static const TypeInfo connex_type = {
@@ -145,6 +146,7 @@ static void verdex_class_init(ObjectClass *oc, void *data)
     mc->init = verdex_init;
     mc->ignore_memory_transaction_failures = true;
     mc->default_cpu_type = ARM_CPU_TYPE_NAME("pxa270-c0");
+    mc->deprecated_reason = "Unmaintained";
 }
 
 static const TypeInfo verdex_type = {
-- 
2.15.0

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [Qemu-devel] [RFC PATCH 4/6] hw/ppc: deprecate the PReP machine
  2017-11-08  2:28 [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Philippe Mathieu-Daudé
                   ` (2 preceding siblings ...)
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 3/6] hw/arm: deprecate the Gumstix boards Philippe Mathieu-Daudé
@ 2017-11-08  2:28 ` Philippe Mathieu-Daudé
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines Philippe Mathieu-Daudé
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2017-11-08  2:28 UTC (permalink / raw)
  To: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Hervé Poussineau,
	David Gibson, Alexander Graf
  Cc: Philippe Mathieu-Daudé, qemu-devel, qemu-ppc

It is obsoleted by the "40p" machine.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/ppc/prep.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 6f8accc397..c032ec3af1 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -682,6 +682,7 @@ static void prep_machine_init(MachineClass *mc)
     mc->max_cpus = MAX_CPUS;
     mc->default_boot_order = "cad";
     mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("602");
+    mc->deprecated_reason = "Obsoleted by the \"40p\" machine";
 }
 
 static int prep_set_cmos_checksum(DeviceState *dev, void *opaque)
-- 
2.15.0

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines
  2017-11-08  2:28 [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Philippe Mathieu-Daudé
                   ` (3 preceding siblings ...)
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 4/6] hw/ppc: deprecate the PReP machine Philippe Mathieu-Daudé
@ 2017-11-08  2:28 ` Philippe Mathieu-Daudé
  2017-11-08  2:48   ` Alexey Kardashevskiy
                     ` (2 more replies)
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine Philippe Mathieu-Daudé
                   ` (2 subsequent siblings)
  7 siblings, 3 replies; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2017-11-08  2:28 UTC (permalink / raw)
  To: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Michael S. Tsirkin,
	Richard Henderson
  Cc: Philippe Mathieu-Daudé, qemu-devel

Both are deprecated since 2.9.0

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/i386/pc_piix.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index f79d5cb694..c462b702ff 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -941,6 +941,7 @@ static void pc_i440fx_0_11_machine_options(MachineClass *m)
     pc_i440fx_0_12_machine_options(m);
     m->hw_version = "0.11";
     SET_MACHINE_COMPAT(m, PC_COMPAT_0_11);
+    m->deprecated_reason = "Too old";
 }
 
 DEFINE_I440FX_MACHINE(v0_11, "pc-0.11", pc_compat_0_13,
@@ -976,6 +977,7 @@ static void pc_i440fx_0_10_machine_options(MachineClass *m)
     pc_i440fx_0_11_machine_options(m);
     m->hw_version = "0.10";
     SET_MACHINE_COMPAT(m, PC_COMPAT_0_10);
+    m->deprecated_reason = "Too old";
 }
 
 DEFINE_I440FX_MACHINE(v0_10, "pc-0.10", pc_compat_0_13,
-- 
2.15.0

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine
  2017-11-08  2:28 [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Philippe Mathieu-Daudé
                   ` (4 preceding siblings ...)
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines Philippe Mathieu-Daudé
@ 2017-11-08  2:28 ` Philippe Mathieu-Daudé
  2017-11-08  3:29   ` Philippe Mathieu-Daudé
  2017-11-08  9:09   ` Daniel P. Berrange
  2017-11-08  9:10 ` [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Daniel P. Berrange
  2018-05-04 17:15 ` Thomas Huth
  7 siblings, 2 replies; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2017-11-08  2:28 UTC (permalink / raw)
  To: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Michael S. Tsirkin,
	Richard Henderson
  Cc: Philippe Mathieu-Daudé, qemu-devel

Deprecated since 2.9.0, guests should be able to use "pc" instead.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/i386/pc_piix.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index c462b702ff..df4669c6d3 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -1114,6 +1114,7 @@ static void isapc_machine_options(MachineClass *m)
     pcmc->smbios_legacy_mode = true;
     pcmc->has_reserved_memory = false;
     m->default_cpu_type = X86_CPU_TYPE_NAME("486");
+    m->deprecated_reason = "Use the \"pc\" machine instead";
 }
 
 DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
-- 
2.15.0

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines Philippe Mathieu-Daudé
@ 2017-11-08  2:48   ` Alexey Kardashevskiy
  2017-11-08  3:28     ` Philippe Mathieu-Daudé
  2017-11-08  9:16   ` Daniel P. Berrange
  2017-11-08 11:36   ` Thomas Huth
  2 siblings, 1 reply; 35+ messages in thread
From: Alexey Kardashevskiy @ 2017-11-08  2:48 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé,
	Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Michael S. Tsirkin,
	Richard Henderson
  Cc: qemu-devel

On 08/11/17 13:28, Philippe Mathieu-Daudé wrote:
> Both are deprecated since 2.9.0

May be so but I could not find where this happened in git history:

[vpl1 qemu]$ git log -n1 --grep 'pc-0.10'
f6d5a0bad2 2 years, 5 months ago Eduardo Habkost piix: Define PC_COMPAT_0_10

Having some pointers in the commit log would be helpful imho, like [2/6].


> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  hw/i386/pc_piix.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index f79d5cb694..c462b702ff 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -941,6 +941,7 @@ static void pc_i440fx_0_11_machine_options(MachineClass *m)
>      pc_i440fx_0_12_machine_options(m);
>      m->hw_version = "0.11";
>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_11);
> +    m->deprecated_reason = "Too old";
>  }
>  
>  DEFINE_I440FX_MACHINE(v0_11, "pc-0.11", pc_compat_0_13,
> @@ -976,6 +977,7 @@ static void pc_i440fx_0_10_machine_options(MachineClass *m)
>      pc_i440fx_0_11_machine_options(m);
>      m->hw_version = "0.10";
>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_10);
> +    m->deprecated_reason = "Too old";
>  }
>  
>  DEFINE_I440FX_MACHINE(v0_10, "pc-0.10", pc_compat_0_13,
> 


-- 
Alexey

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines
  2017-11-08  2:48   ` Alexey Kardashevskiy
@ 2017-11-08  3:28     ` Philippe Mathieu-Daudé
  2017-11-08  9:13       ` Daniel P. Berrange
  0 siblings, 1 reply; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2017-11-08  3:28 UTC (permalink / raw)
  To: Alexey Kardashevskiy, Peter Maydell, Alistair Francis,
	Paolo Bonzini, Thomas Huth, Eduardo Habkost, Marcel Apfelbaum,
	Michael S. Tsirkin, Richard Henderson
  Cc: qemu-devel

Hi Alexey,

On 11/07/2017 11:48 PM, Alexey Kardashevskiy wrote:
> On 08/11/17 13:28, Philippe Mathieu-Daudé wrote:
>> Both are deprecated since 2.9.0
> 
> May be so but I could not find where this happened in git history:
> 
> [vpl1 qemu]$ git log -n1 --grep 'pc-0.10'
> f6d5a0bad2 2 years, 5 months ago Eduardo Habkost piix: Define PC_COMPAT_0_10
> 
> Having some pointers in the commit log would be helpful imho, like [2/6].

Ok! If there is positive feedback on this series I'll respin trying to
be more verbose.

I took "2.9.0" from the wiki history [1], which is the formal way to go
as I understand:

Before an "interface" can be removed, there needs to be a clear
transition plan for doing so. This means it should be added to this wiki
page, and that there have to be at least two public releases of QEMU
where the interface still works, but issues a warning when used. Two
public releases are required so that the users have at least one
development cycle to complain if they think that there is a good reason
that the interface should not be removed. The warning should say that
the interface is deprecated / going away soon, with a pointer to
documentation or similar information about its replacement syntax.

[1]
https://wiki.qemu.org/index.php?title=Features/LegacyRemoval&action=history

>>
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>>  hw/i386/pc_piix.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>> index f79d5cb694..c462b702ff 100644
>> --- a/hw/i386/pc_piix.c
>> +++ b/hw/i386/pc_piix.c
>> @@ -941,6 +941,7 @@ static void pc_i440fx_0_11_machine_options(MachineClass *m)
>>      pc_i440fx_0_12_machine_options(m);
>>      m->hw_version = "0.11";
>>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_11);
>> +    m->deprecated_reason = "Too old";
>>  }
>>  
>>  DEFINE_I440FX_MACHINE(v0_11, "pc-0.11", pc_compat_0_13,
>> @@ -976,6 +977,7 @@ static void pc_i440fx_0_10_machine_options(MachineClass *m)
>>      pc_i440fx_0_11_machine_options(m);
>>      m->hw_version = "0.10";
>>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_10);
>> +    m->deprecated_reason = "Too old";
>>  }
>>  
>>  DEFINE_I440FX_MACHINE(v0_10, "pc-0.10", pc_compat_0_13,
>>

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine Philippe Mathieu-Daudé
@ 2017-11-08  3:29   ` Philippe Mathieu-Daudé
  2017-11-08  9:09   ` Daniel P. Berrange
  1 sibling, 0 replies; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2017-11-08  3:29 UTC (permalink / raw)
  To: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Michael S. Tsirkin,
	Richard Henderson
  Cc: qemu-devel

On 11/07/2017 11:28 PM, Philippe Mathieu-Daudé wrote:
> Deprecated since 2.9.0, guests should be able to use "pc" instead.

I forgot to add Paolo's comment:

"but firmware code paths would be different, do we care?"

> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  hw/i386/pc_piix.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index c462b702ff..df4669c6d3 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -1114,6 +1114,7 @@ static void isapc_machine_options(MachineClass *m)
>      pcmc->smbios_legacy_mode = true;
>      pcmc->has_reserved_memory = false;
>      m->default_cpu_type = X86_CPU_TYPE_NAME("486");
> +    m->deprecated_reason = "Use the \"pc\" machine instead";
>  }
>  
>  DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
> 

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine Philippe Mathieu-Daudé
  2017-11-08  3:29   ` Philippe Mathieu-Daudé
@ 2017-11-08  9:09   ` Daniel P. Berrange
  2017-11-08  9:44     ` Gerd Hoffmann
  1 sibling, 1 reply; 35+ messages in thread
From: Daniel P. Berrange @ 2017-11-08  9:09 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Michael S. Tsirkin,
	Richard Henderson, qemu-devel

On Tue, Nov 07, 2017 at 11:28:28PM -0300, Philippe Mathieu-Daudé wrote:
> Deprecated since 2.9.0, guests should be able to use "pc" instead.

Isn't isapc important to allow QEMU to old operating systems that
predate the PCI era. I do recall seeing some messages about specific
cases where you cannot use the 'pc' machine type and we suggested
used of 'isapc' instead, but can't remember the exact details..

I know that's not a typical usecase for modern cloud / data center
virt, but it is interesting for usage of QEMU as a archeology tool,
so I'm loathe to see this removed unless it is demonstrably causing
an unacceptable maint burden to keep it.

> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  hw/i386/pc_piix.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index c462b702ff..df4669c6d3 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -1114,6 +1114,7 @@ static void isapc_machine_options(MachineClass *m)
>      pcmc->smbios_legacy_mode = true;
>      pcmc->has_reserved_memory = false;
>      m->default_cpu_type = X86_CPU_TYPE_NAME("486");
> +    m->deprecated_reason = "Use the \"pc\" machine instead";
>  }
>  
>  DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,

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 :|

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines
  2017-11-08  2:28 [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Philippe Mathieu-Daudé
                   ` (5 preceding siblings ...)
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine Philippe Mathieu-Daudé
@ 2017-11-08  9:10 ` Daniel P. Berrange
  2018-05-04 17:15 ` Thomas Huth
  7 siblings, 0 replies; 35+ messages in thread
From: Daniel P. Berrange @ 2017-11-08  9:10 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Michael S. Tsirkin,
	Richard Henderson, Hervé Poussineau, David Gibson,
	Alexander Graf, Michael Roth, qemu-devel

On Tue, Nov 07, 2017 at 11:28:22PM -0300, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> This series intends to provide a simple and common way to deprecate
> machines between releases. It may be extended to deprecate devices.
> 
> I started with the machines list from:
> 
>   https://wiki.qemu.org/Features/LegacyRemoval#Deprecated_machines
> 
> Comment welcomed :)
> 
> Regards,
> 
> Phil.
> 
> Alistair Francis (1):
>   hw/arm: deprecate the EP108 board
> 
> Philippe Mathieu-Daudé (5):
>   machine: add a deprecated_reason property
>   hw/arm: deprecate the Gumstix boards
>   hw/ppc: deprecate the PReP machine
>   hw/i386: deprecate the pc-0.10 and pc-0.11 machines
>   hw/i386: deprecate the "isapc" machine
> 
>  include/hw/boards.h  | 1 +
>  hw/arm/gumstix.c     | 2 ++
>  hw/arm/xlnx-zcu102.c | 6 +++++-
>  hw/i386/pc_piix.c    | 3 +++
>  hw/ppc/prep.c        | 1 +
>  vl.c                 | 7 +++++++
>  6 files changed, 19 insertions(+), 1 deletion(-)

Unless listed in the qemu-doc.texi "Deprecated features" appendix,
things are not considered deprecated...

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 :|

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines
  2017-11-08  3:28     ` Philippe Mathieu-Daudé
@ 2017-11-08  9:13       ` Daniel P. Berrange
  2017-11-08 10:43         ` Thomas Huth
  0 siblings, 1 reply; 35+ messages in thread
From: Daniel P. Berrange @ 2017-11-08  9:13 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Alexey Kardashevskiy, Peter Maydell, Alistair Francis,
	Paolo Bonzini, Thomas Huth, Eduardo Habkost, Marcel Apfelbaum,
	Michael S. Tsirkin, Richard Henderson, qemu-devel

On Wed, Nov 08, 2017 at 12:28:00AM -0300, Philippe Mathieu-Daudé wrote:
> Hi Alexey,
> 
> On 11/07/2017 11:48 PM, Alexey Kardashevskiy wrote:
> > On 08/11/17 13:28, Philippe Mathieu-Daudé wrote:
> >> Both are deprecated since 2.9.0
> > 
> > May be so but I could not find where this happened in git history:
> > 
> > [vpl1 qemu]$ git log -n1 --grep 'pc-0.10'
> > f6d5a0bad2 2 years, 5 months ago Eduardo Habkost piix: Define PC_COMPAT_0_10
> > 
> > Having some pointers in the commit log would be helpful imho, like [2/6].
> 
> Ok! If there is positive feedback on this series I'll respin trying to
> be more verbose.
> 
> I took "2.9.0" from the wiki history [1], which is the formal way to go
> as I understand:

No, the wiki page content was just an initial jumping off point for
discussions.  The formal list of what's deprecated is kept in the
qemu-doc.texi file in the "Deprecated features" appendix.

We really ought to remove most of the content from that wiki page
and just point to the formal docs,  to avoid continued confusion
like this.

> 
> Before an "interface" can be removed, there needs to be a clear
> transition plan for doing so. This means it should be added to this wiki
> page, and that there have to be at least two public releases of QEMU
> where the interface still works, but issues a warning when used. Two
> public releases are required so that the users have at least one
> development cycle to complain if they think that there is a good reason
> that the interface should not be removed. The warning should say that
> the interface is deprecated / going away soon, with a pointer to
> documentation or similar information about its replacement syntax.
> 
> [1]
> https://wiki.qemu.org/index.php?title=Features/LegacyRemoval&action=history
> 
> >>
> >> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> >> ---
> >>  hw/i386/pc_piix.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> >> index f79d5cb694..c462b702ff 100644
> >> --- a/hw/i386/pc_piix.c
> >> +++ b/hw/i386/pc_piix.c
> >> @@ -941,6 +941,7 @@ static void pc_i440fx_0_11_machine_options(MachineClass *m)
> >>      pc_i440fx_0_12_machine_options(m);
> >>      m->hw_version = "0.11";
> >>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_11);
> >> +    m->deprecated_reason = "Too old";
> >>  }
> >>  
> >>  DEFINE_I440FX_MACHINE(v0_11, "pc-0.11", pc_compat_0_13,
> >> @@ -976,6 +977,7 @@ static void pc_i440fx_0_10_machine_options(MachineClass *m)
> >>      pc_i440fx_0_11_machine_options(m);
> >>      m->hw_version = "0.10";
> >>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_10);
> >> +    m->deprecated_reason = "Too old";
> >>  }
> >>  
> >>  DEFINE_I440FX_MACHINE(v0_10, "pc-0.10", pc_compat_0_13,
> >>
> 
> 

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 :|

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines Philippe Mathieu-Daudé
  2017-11-08  2:48   ` Alexey Kardashevskiy
@ 2017-11-08  9:16   ` Daniel P. Berrange
  2017-11-08 10:15     ` Thomas Huth
  2017-11-08 11:36   ` Thomas Huth
  2 siblings, 1 reply; 35+ messages in thread
From: Daniel P. Berrange @ 2017-11-08  9:16 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Michael S. Tsirkin,
	Richard Henderson, qemu-devel

On Tue, Nov 07, 2017 at 11:28:27PM -0300, Philippe Mathieu-Daudé wrote:
> Both are deprecated since 2.9.0
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  hw/i386/pc_piix.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index f79d5cb694..c462b702ff 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -941,6 +941,7 @@ static void pc_i440fx_0_11_machine_options(MachineClass *m)
>      pc_i440fx_0_12_machine_options(m);
>      m->hw_version = "0.11";
>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_11);
> +    m->deprecated_reason = "Too old";
>  }
>  
>  DEFINE_I440FX_MACHINE(v0_11, "pc-0.11", pc_compat_0_13,
> @@ -976,6 +977,7 @@ static void pc_i440fx_0_10_machine_options(MachineClass *m)
>      pc_i440fx_0_11_machine_options(m);
>      m->hw_version = "0.10";
>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_10);
> +    m->deprecated_reason = "Too old";
>  }

Any deprecation message should give users useful information about what
they should do instead to avoid the problem.

More generally though, what would removing these two machines types allow
us to actually achieve ? Seems quite arbitrary to pick 0.10 and 0.11 but
leave the other 20+ machine types.

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 :|

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 2/6] hw/arm: deprecate the EP108 board
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 2/6] hw/arm: deprecate the EP108 board Philippe Mathieu-Daudé
@ 2017-11-08  9:17   ` Daniel P. Berrange
  0 siblings, 0 replies; 35+ messages in thread
From: Daniel P. Berrange @ 2017-11-08  9:17 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Edgar E. Iglesias, qemu-arm,
	qemu-devel

On Tue, Nov 07, 2017 at 11:28:24PM -0300, Philippe Mathieu-Daudé wrote:
> From: Alistair Francis <alistair.francis@xilinx.com>
> 
> The EP108 was an early access development board that is no longer used.
> Add an info message to convert any users to the ZCU102 instead. On QEMU
> they are both identical.
> 
> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  hw/arm/xlnx-zcu102.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
> index e2d15a1c9d..d42b6e3d3a 100644
> --- a/hw/arm/xlnx-zcu102.c
> +++ b/hw/arm/xlnx-zcu102.c
> @@ -164,6 +164,8 @@ static void xlnx_ep108_init(MachineState *machine)
>  {
>      XlnxZCU102 *s = EP108_MACHINE(machine);
>  
> +    info_report("Please use the ZCU102 machine instead of this machine.");

Why do we need this, in addition to the generic deprecation message that
says basically the same thing ?

> +
>      xlnx_zynqmp_init(s, machine);
>  }
>  
> @@ -180,11 +182,13 @@ static void xlnx_ep108_machine_class_init(ObjectClass *oc, void *data)
>  {
>      MachineClass *mc = MACHINE_CLASS(oc);
>  
> -    mc->desc = "Xilinx ZynqMP EP108 board (Deprecated, please use xlnx-zcu102)";
> +    mc->desc = "Xilinx ZynqMP EP108 board";
>      mc->init = xlnx_ep108_init;
>      mc->block_default_type = IF_IDE;
>      mc->units_per_default_bus = 1;
>      mc->ignore_memory_transaction_failures = true;
> +    mc->deprecated_reason =
> +        "The ZCU102 machine has the same features supported";
>  }

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 :|

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine
  2017-11-08  9:09   ` Daniel P. Berrange
@ 2017-11-08  9:44     ` Gerd Hoffmann
  2017-11-08 10:05       ` Thomas Huth
  0 siblings, 1 reply; 35+ messages in thread
From: Gerd Hoffmann @ 2017-11-08  9:44 UTC (permalink / raw)
  To: Daniel P. Berrange
  Cc: Philippe Mathieu-Daudé,
	Peter Maydell, Thomas Huth, Eduardo Habkost, Michael S. Tsirkin,
	qemu-devel, Alistair Francis, Marcel Apfelbaum, Paolo Bonzini,
	Richard Henderson

On Wed, Nov 08, 2017 at 09:09:00AM +0000, Daniel P. Berrange wrote:
> On Tue, Nov 07, 2017 at 11:28:28PM -0300, Philippe Mathieu-Daudé wrote:
> > Deprecated since 2.9.0, guests should be able to use "pc" instead.
> 
> Isn't isapc important to allow QEMU to old operating systems that
> predate the PCI era.

They should work fine.  The early pci chipsets like the piix4 have
built-in backward compatibility.  The IDE controller can be driven by
simply accessing the isa ide ports.  Likewise vga.  You can plug in ne2k
(we have both isa and pci variants) for ethernet and sb16 (isa too) for
sound.

That should make guests which don't know anything about pci happy.

> I do recall seeing some messages about specific
> cases where you cannot use the 'pc' machine type and we suggested
> used of 'isapc' instead, but can't remember the exact details..

I'd like to see such use cases where isapc is actually required.

> I know that's not a typical usecase for modern cloud / data center
> virt, but it is interesting for usage of QEMU as a archeology tool,
> so I'm loathe to see this removed unless it is demonstrably causing
> an unacceptable maint burden to keep it.

Well, nobody maintains it.  Nobody tests it.

>From a firmware point of view it *is* quite different from pc.  isapc
has no rom shadowing, so firmware init code paths are different.  isapc
has no resource management, so isa-vga maps the vesa 2.0 framebuffer at
a hardcoded address instead of placing it in a pci bar and the vgabios
has to know where it is.

So there is a non-zero chance that things break by accident.  IIRC we
even had a qemu release with broken isapc in the past ...

cheers,
  Gerd

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine
  2017-11-08  9:44     ` Gerd Hoffmann
@ 2017-11-08 10:05       ` Thomas Huth
  0 siblings, 0 replies; 35+ messages in thread
From: Thomas Huth @ 2017-11-08 10:05 UTC (permalink / raw)
  To: Gerd Hoffmann, Daniel P. Berrange
  Cc: Philippe Mathieu-Daudé,
	Peter Maydell, Eduardo Habkost, Michael S. Tsirkin, qemu-devel,
	Alistair Francis, Marcel Apfelbaum, Paolo Bonzini,
	Richard Henderson

On 08.11.2017 10:44, Gerd Hoffmann wrote:
> On Wed, Nov 08, 2017 at 09:09:00AM +0000, Daniel P. Berrange wrote:
>> On Tue, Nov 07, 2017 at 11:28:28PM -0300, Philippe Mathieu-Daudé wrote:
>>> Deprecated since 2.9.0, guests should be able to use "pc" instead.
>>
>> Isn't isapc important to allow QEMU to old operating systems that
>> predate the PCI era.
> 
> They should work fine.  The early pci chipsets like the piix4 have
> built-in backward compatibility.  The IDE controller can be driven by
> simply accessing the isa ide ports.  Likewise vga.  You can plug in ne2k
> (we have both isa and pci variants) for ethernet and sb16 (isa too) for
> sound.
> 
> That should make guests which don't know anything about pci happy.
> 
>> I do recall seeing some messages about specific
>> cases where you cannot use the 'pc' machine type and we suggested
>> used of 'isapc' instead, but can't remember the exact details..
> 
> I'd like to see such use cases where isapc is actually required.

Just my 0.02 €: I like the idea of keeping isapc. It's a way to remind
the x86 folks that there are also architectures without PCI / APIC /
ACPI. And this helped to spot some bugs in some HMP commands in the past
already.

> Well, nobody maintains it.  Nobody tests it.

At least we've got the automatic boot-serial-test now that checks that
the machine is not completely broken.

 Thomas

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines
  2017-11-08  9:16   ` Daniel P. Berrange
@ 2017-11-08 10:15     ` Thomas Huth
  0 siblings, 0 replies; 35+ messages in thread
From: Thomas Huth @ 2017-11-08 10:15 UTC (permalink / raw)
  To: Daniel P. Berrange, Philippe Mathieu-Daudé
  Cc: Peter Maydell, Alistair Francis, Paolo Bonzini, Eduardo Habkost,
	Marcel Apfelbaum, Michael S. Tsirkin, Richard Henderson,
	qemu-devel

On 08.11.2017 10:16, Daniel P. Berrange wrote:
> On Tue, Nov 07, 2017 at 11:28:27PM -0300, Philippe Mathieu-Daudé wrote:
>> Both are deprecated since 2.9.0
>>
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>>  hw/i386/pc_piix.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>> index f79d5cb694..c462b702ff 100644
>> --- a/hw/i386/pc_piix.c
>> +++ b/hw/i386/pc_piix.c
>> @@ -941,6 +941,7 @@ static void pc_i440fx_0_11_machine_options(MachineClass *m)
>>      pc_i440fx_0_12_machine_options(m);
>>      m->hw_version = "0.11";
>>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_11);
>> +    m->deprecated_reason = "Too old";
>>  }
>>  
>>  DEFINE_I440FX_MACHINE(v0_11, "pc-0.11", pc_compat_0_13,
>> @@ -976,6 +977,7 @@ static void pc_i440fx_0_10_machine_options(MachineClass *m)
>>      pc_i440fx_0_11_machine_options(m);
>>      m->hw_version = "0.10";
>>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_10);
>> +    m->deprecated_reason = "Too old";
>>  }
> 
> Any deprecation message should give users useful information about what
> they should do instead to avoid the problem.

+1

> More generally though, what would removing these two machines types allow
> us to actually achieve ? Seems quite arbitrary to pick 0.10 and 0.11 but
> leave the other 20+ machine types.

We've discussed this a couple of months ago on the mailing list: The
basic idea is that the oldest machine type that is still in use is 0.12
(as a base for the RHEL 6 machines), so we should avoid to get rid of
that code yet. But 0.10 and 0.11 very likely do not have any users
anymore, so it should be OK to deprecate them.

 Thomas

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property Philippe Mathieu-Daudé
@ 2017-11-08 10:23   ` Thomas Huth
  2017-11-08 10:27     ` Daniel P. Berrange
  2017-11-08 20:29   ` Eduardo Habkost
  1 sibling, 1 reply; 35+ messages in thread
From: Thomas Huth @ 2017-11-08 10:23 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé,
	Peter Maydell, Alistair Francis, Paolo Bonzini, Eduardo Habkost,
	Marcel Apfelbaum, Michael Roth
  Cc: qemu-devel

On 08.11.2017 03:28, Philippe Mathieu-Daudé wrote:
> If a machine has the deprecated_reason property set:
> - it won't get listed anymore by the "-M help" command,
> - a warning will be displayed if the machine is used.
> 
> Example:
>   $ ppc-softmmu/qemu-system-ppc -M prep
>   qemu-system-ppc: -M prep: warning: The PowerPC PREP platform machine is deprecated (Obsoleted by the "40p" machine)
>   [machine starting ...]
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  include/hw/boards.h | 1 +
>  vl.c                | 7 +++++++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 191a5b3cd8..4d5c180968 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -182,6 +182,7 @@ struct MachineClass {
>      const char *default_boot_order;
>      const char *default_display;
>      GArray *compat_props;
> +    const char *deprecated_reason;
>      const char *hw_version;
>      ram_addr_t default_ram_size;
>      const char *default_cpu_type;
> diff --git a/vl.c b/vl.c
> index ec299099ff..9ed4648af2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2742,6 +2742,10 @@ static gint machine_class_cmp(gconstpointer a, gconstpointer b)
>      }
>      if (mc) {
>          g_slist_free(machines);
> +        if (mc->deprecated_reason) {
> +            warn_report("The %s machine is deprecated (%s)",
> +                        mc->desc, mc->deprecated_reason);
> +        }

Just cosmetic, but maybe rather put that into select_machine() instead?

>          return mc;
>      }
>      if (name && !is_help_option(name)) {
> @@ -2752,6 +2756,9 @@ static gint machine_class_cmp(gconstpointer a, gconstpointer b)
>          machines = g_slist_sort(machines, machine_class_cmp);
>          for (el = machines; el; el = el->next) {
>              MachineClass *mc = el->data;
> +            if (mc->deprecated_reason) {
> +                continue;
> +            }

Not sure, but maybe it would be more user-friendly to still list the
machine, but add a "(deprecated)" string at the end?

 Thomas

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property
  2017-11-08 10:23   ` Thomas Huth
@ 2017-11-08 10:27     ` Daniel P. Berrange
  0 siblings, 0 replies; 35+ messages in thread
From: Daniel P. Berrange @ 2017-11-08 10:27 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Philippe Mathieu-Daudé,
	Peter Maydell, Alistair Francis, Paolo Bonzini, Eduardo Habkost,
	Marcel Apfelbaum, Michael Roth, qemu-devel

On Wed, Nov 08, 2017 at 11:23:53AM +0100, Thomas Huth wrote:
> On 08.11.2017 03:28, Philippe Mathieu-Daudé wrote:
> > If a machine has the deprecated_reason property set:
> > - it won't get listed anymore by the "-M help" command,
> > - a warning will be displayed if the machine is used.
> > 
> > Example:
> >   $ ppc-softmmu/qemu-system-ppc -M prep
> >   qemu-system-ppc: -M prep: warning: The PowerPC PREP platform machine is deprecated (Obsoleted by the "40p" machine)
> >   [machine starting ...]
> > 
> > Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> > ---
> >  include/hw/boards.h | 1 +
> >  vl.c                | 7 +++++++
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/include/hw/boards.h b/include/hw/boards.h
> > index 191a5b3cd8..4d5c180968 100644
> > --- a/include/hw/boards.h
> > +++ b/include/hw/boards.h
> > @@ -182,6 +182,7 @@ struct MachineClass {
> >      const char *default_boot_order;
> >      const char *default_display;
> >      GArray *compat_props;
> > +    const char *deprecated_reason;
> >      const char *hw_version;
> >      ram_addr_t default_ram_size;
> >      const char *default_cpu_type;
> > diff --git a/vl.c b/vl.c
> > index ec299099ff..9ed4648af2 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -2742,6 +2742,10 @@ static gint machine_class_cmp(gconstpointer a, gconstpointer b)
> >      }
> >      if (mc) {
> >          g_slist_free(machines);
> > +        if (mc->deprecated_reason) {
> > +            warn_report("The %s machine is deprecated (%s)",
> > +                        mc->desc, mc->deprecated_reason);
> > +        }
> 
> Just cosmetic, but maybe rather put that into select_machine() instead?
> 
> >          return mc;
> >      }
> >      if (name && !is_help_option(name)) {
> > @@ -2752,6 +2756,9 @@ static gint machine_class_cmp(gconstpointer a, gconstpointer b)
> >          machines = g_slist_sort(machines, machine_class_cmp);
> >          for (el = machines; el; el = el->next) {
> >              MachineClass *mc = el->data;
> > +            if (mc->deprecated_reason) {
> > +                continue;
> > +            }
> 
> Not sure, but maybe it would be more user-friendly to still list the
> machine, but add a "(deprecated)" string at the end?

Yeah, as long as it still exists, it should be visible.

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 :|

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines
  2017-11-08  9:13       ` Daniel P. Berrange
@ 2017-11-08 10:43         ` Thomas Huth
  0 siblings, 0 replies; 35+ messages in thread
From: Thomas Huth @ 2017-11-08 10:43 UTC (permalink / raw)
  To: Daniel P. Berrange, Philippe Mathieu-Daudé
  Cc: Alexey Kardashevskiy, Peter Maydell, Alistair Francis,
	Paolo Bonzini, Eduardo Habkost, Marcel Apfelbaum,
	Michael S. Tsirkin, Richard Henderson, qemu-devel

On 08.11.2017 10:13, Daniel P. Berrange wrote:
> On Wed, Nov 08, 2017 at 12:28:00AM -0300, Philippe Mathieu-Daudé wrote:
>> Hi Alexey,
>>
>> On 11/07/2017 11:48 PM, Alexey Kardashevskiy wrote:
>>> On 08/11/17 13:28, Philippe Mathieu-Daudé wrote:
>>>> Both are deprecated since 2.9.0
>>>
>>> May be so but I could not find where this happened in git history:
>>>
>>> [vpl1 qemu]$ git log -n1 --grep 'pc-0.10'
>>> f6d5a0bad2 2 years, 5 months ago Eduardo Habkost piix: Define PC_COMPAT_0_10
>>>
>>> Having some pointers in the commit log would be helpful imho, like [2/6].
>>
>> Ok! If there is positive feedback on this series I'll respin trying to
>> be more verbose.
>>
>> I took "2.9.0" from the wiki history [1], which is the formal way to go
>> as I understand:
> 
> No, the wiki page content was just an initial jumping off point for
> discussions.  The formal list of what's deprecated is kept in the
> qemu-doc.texi file in the "Deprecated features" appendix.
> 
> We really ought to remove most of the content from that wiki page
> and just point to the formal docs,  to avoid continued confusion
> like this.

I've changed the wording on the wiki page and added a pointer to the
qemu-doc there, so it's hopefully now clearer that the qemu-doc is the
mandatory list of deprecated features / interfaces.

 Thomas

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines Philippe Mathieu-Daudé
  2017-11-08  2:48   ` Alexey Kardashevskiy
  2017-11-08  9:16   ` Daniel P. Berrange
@ 2017-11-08 11:36   ` Thomas Huth
  2 siblings, 0 replies; 35+ messages in thread
From: Thomas Huth @ 2017-11-08 11:36 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé,
	Peter Maydell, Alistair Francis, Paolo Bonzini, Eduardo Habkost,
	Marcel Apfelbaum, Michael S. Tsirkin, Richard Henderson
  Cc: qemu-devel

On 08.11.2017 03:28, Philippe Mathieu-Daudé wrote:
> Both are deprecated since 2.9.0
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  hw/i386/pc_piix.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index f79d5cb694..c462b702ff 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -941,6 +941,7 @@ static void pc_i440fx_0_11_machine_options(MachineClass *m)
>      pc_i440fx_0_12_machine_options(m);
>      m->hw_version = "0.11";
>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_11);
> +    m->deprecated_reason = "Too old";

As Daniel already mentioned it, I'd also suggest to use a more helpful
message instead (e.g. "Use a newer version of pc-i440fx instead" ?).

>  }
>  
>  DEFINE_I440FX_MACHINE(v0_11, "pc-0.11", pc_compat_0_13,
> @@ -976,6 +977,7 @@ static void pc_i440fx_0_10_machine_options(MachineClass *m)
>      pc_i440fx_0_11_machine_options(m);
>      m->hw_version = "0.10";
>      SET_MACHINE_COMPAT(m, PC_COMPAT_0_10);
> +    m->deprecated_reason = "Too old";

I think you don't need the second hunk here since the function is
calling pc_i440fx_0_11_machine_options(), too.

 Thomas

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property
  2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property Philippe Mathieu-Daudé
  2017-11-08 10:23   ` Thomas Huth
@ 2017-11-08 20:29   ` Eduardo Habkost
  2018-01-22  2:10     ` Philippe Mathieu-Daudé
  1 sibling, 1 reply; 35+ messages in thread
From: Eduardo Habkost @ 2017-11-08 20:29 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Marcel Apfelbaum, Michael Roth, qemu-devel

On Tue, Nov 07, 2017 at 11:28:23PM -0300, Philippe Mathieu-Daudé wrote:
> If a machine has the deprecated_reason property set:
> - it won't get listed anymore by the "-M help" command,
> - a warning will be displayed if the machine is used.
> 
> Example:
>   $ ppc-softmmu/qemu-system-ppc -M prep
>   qemu-system-ppc: -M prep: warning: The PowerPC PREP platform machine is deprecated (Obsoleted by the "40p" machine)
>   [machine starting ...]
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  include/hw/boards.h | 1 +
>  vl.c                | 7 +++++++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 191a5b3cd8..4d5c180968 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -182,6 +182,7 @@ struct MachineClass {
>      const char *default_boot_order;
>      const char *default_display;
>      GArray *compat_props;
> +    const char *deprecated_reason;

This series introduces 5 different flavors of deprecation
messages:

* "Too old"
* "Unmaintained"
* "The ZCU102 machine has the same features supported"
* "Use the \"pc\" machine instead"
* "Obsoleted by the \"40p\" machine"

Can we clearly document guidelines and examples for values of
this field, to help ensure consistency?

Examples of questions that could be answered in the field
documentation:

* Should the message start with an uppercase letter?
* Should it really explain _why_ it was deprecated, or is a
  simple "please use xlnx-zcu102 instead" good enough?
* Which of the following is preferred:
  * "obsoleted by the \"pc\" machine"
  * "obsoleted by \"pc\""
  * "use \"pc\" instead"
  * "too old, use \"pc\" instead"
  * "too old; use \"pc\" instead"
  * <something else?>


Minor suggestion: name the field 'deprecation_reason' instead of
'deprecated_reason'.

>      const char *hw_version;
>      ram_addr_t default_ram_size;
>      const char *default_cpu_type;
> diff --git a/vl.c b/vl.c
> index ec299099ff..9ed4648af2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2742,6 +2742,10 @@ static gint machine_class_cmp(gconstpointer a, gconstpointer b)
>      }
>      if (mc) {
>          g_slist_free(machines);
> +        if (mc->deprecated_reason) {
> +            warn_report("The %s machine is deprecated (%s)",
> +                        mc->desc, mc->deprecated_reason);

I would use mc->name instead of mc->desc.


> +        }
>          return mc;
>      }
>      if (name && !is_help_option(name)) {
> @@ -2752,6 +2756,9 @@ static gint machine_class_cmp(gconstpointer a, gconstpointer b)
>          machines = g_slist_sort(machines, machine_class_cmp);
>          for (el = machines; el; el = el->next) {
>              MachineClass *mc = el->data;
> +            if (mc->deprecated_reason) {
> +                continue;
> +            }
>              if (mc->alias) {
>                  printf("%-20s %s (alias of %s)\n", mc->alias, mc->desc, mc->name);
>              }
> -- 
> 2.15.0
> 

-- 
Eduardo

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property
  2017-11-08 20:29   ` Eduardo Habkost
@ 2018-01-22  2:10     ` Philippe Mathieu-Daudé
  2018-01-22  6:21       ` Thomas Huth
  0 siblings, 1 reply; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2018-01-22  2:10 UTC (permalink / raw)
  Cc: Eduardo Habkost, Peter Maydell, Alistair Francis, Paolo Bonzini,
	Thomas Huth, Marcel Apfelbaum, Michael Roth, qemu-devel

Hi Thomas,

> This series introduces 5 different flavors of deprecation
> messages:
> 
> * "Too old"
> * "Unmaintained"
> * "The ZCU102 machine has the same features supported"
> * "Use the \"pc\" machine instead"
> * "Obsoleted by the \"40p\" machine"
> 
> Can we clearly document guidelines and examples for values of
> this field, to help ensure consistency?
> 
> Examples of questions that could be answered in the field
> documentation:
> 
> * Should the message start with an uppercase letter?
> * Should it really explain _why_ it was deprecated, or is a
>   simple "please use xlnx-zcu102 instead" good enough?
> * Which of the following is preferred:
>   * "obsoleted by the \"pc\" machine"
>   * "obsoleted by \"pc\""
>   * "use \"pc\" instead"
>   * "too old, use \"pc\" instead"
>   * "too old; use \"pc\" instead"
>   * <something else?>

Do you have any preference regarding Eduardo's suggestions?

I see this pattern:

- obsoleted by newer
  -> hint about replacement
- too old, unmaintained (maybe suggest use an older version?)
  -> hint when removal is scheduled

These are also valid for Devices.

Now if we want a consistent guideline, I suggest we clearly document the
deprecated machines/devices in qemu-doc.texi and extract this
information at build time, like trace.h.
At least this will force developers to document their deprecations.

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property
  2018-01-22  2:10     ` Philippe Mathieu-Daudé
@ 2018-01-22  6:21       ` Thomas Huth
  0 siblings, 0 replies; 35+ messages in thread
From: Thomas Huth @ 2018-01-22  6:21 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Eduardo Habkost, Peter Maydell, Alistair Francis, Paolo Bonzini,
	Marcel Apfelbaum, Michael Roth, qemu-devel

On 22.01.2018 03:10, Philippe Mathieu-Daudé wrote:
> Hi Thomas,
> 
>> This series introduces 5 different flavors of deprecation
>> messages:
>>
>> * "Too old"
>> * "Unmaintained"
>> * "The ZCU102 machine has the same features supported"
>> * "Use the \"pc\" machine instead"
>> * "Obsoleted by the \"40p\" machine"
>>
>> Can we clearly document guidelines and examples for values of
>> this field, to help ensure consistency?
>>
>> Examples of questions that could be answered in the field
>> documentation:
>>
>> * Should the message start with an uppercase letter?
>> * Should it really explain _why_ it was deprecated, or is a
>>   simple "please use xlnx-zcu102 instead" good enough?
>> * Which of the following is preferred:
>>   * "obsoleted by the \"pc\" machine"
>>   * "obsoleted by \"pc\""
>>   * "use \"pc\" instead"
>>   * "too old, use \"pc\" instead"
>>   * "too old; use \"pc\" instead"
>>   * <something else?>
> 
> Do you have any preference regarding Eduardo's suggestions?
> 
> I see this pattern:
> 
> - obsoleted by newer
>   -> hint about replacement
> - too old, unmaintained (maybe suggest use an older version?)
>   -> hint when removal is scheduled

I don't mind the exact wording, as long as there is an indication for
the user what to do next (if possible).

> These are also valid for Devices.
> 
> Now if we want a consistent guideline, I suggest we clearly document the
> deprecated machines/devices in qemu-doc.texi and extract this
> information at build time, like trace.h.

While it's a must of course to document deprecations in the qemu-doc,
automatic extraction already sounds like over-engineering to me. I don't
think that we are going to have as much deprecation entries as trace
points, so would an additional automatic mechanism really help a lot here?

 Thomas

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines
  2017-11-08  2:28 [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Philippe Mathieu-Daudé
                   ` (6 preceding siblings ...)
  2017-11-08  9:10 ` [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Daniel P. Berrange
@ 2018-05-04 17:15 ` Thomas Huth
  2018-05-08 15:47   ` Philippe Mathieu-Daudé
  7 siblings, 1 reply; 35+ messages in thread
From: Thomas Huth @ 2018-05-04 17:15 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé,
	Peter Maydell, Alistair Francis, Paolo Bonzini, Thomas Huth,
	Eduardo Habkost, Marcel Apfelbaum, Michael S. Tsirkin,
	Richard Henderson, Hervé Poussineau, David Gibson,
	Alexander Graf, Michael Roth
  Cc: qemu-devel

On 08.11.2017 03:28, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> This series intends to provide a simple and common way to deprecate
> machines between releases. It may be extended to deprecate devices.

*ping*

Philippe, I just discovered your findings wrt to the Gumstix machines on
https://wiki.qemu.org/Features/LegacyRemoval#Deprecated_machines ...
sounds reasonable, so I think we should really continue here and mark
those as deprecated. And pc-0.10 and pc-0.11, too.

Do you have some spare time to respin your patch series?

 Thomas

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines
  2018-05-04 17:15 ` Thomas Huth
@ 2018-05-08 15:47   ` Philippe Mathieu-Daudé
  2018-05-11 13:55     ` [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines) Eduardo Habkost
  0 siblings, 1 reply; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2018-05-08 15:47 UTC (permalink / raw)
  To: Thomas Huth, Peter Maydell, Alex Bennée, Paolo Bonzini,
	Richard Henderson, David Gibson, Alexander Graf
  Cc: Eduardo Habkost, Marcel Apfelbaum, Michael S. Tsirkin,
	Hervé Poussineau, Michael Roth, qemu-devel

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

Hi Thomas,

On 05/04/2018 02:15 PM, Thomas Huth wrote:
> On 08.11.2017 03:28, Philippe Mathieu-Daudé wrote:
>>
>> This series intends to provide a simple and common way to deprecate
>> machines between releases. It may be extended to deprecate devices.
> 
> *ping*
> 
> Philippe, I just discovered your findings wrt to the Gumstix machines on
> https://wiki.qemu.org/Features/LegacyRemoval#Deprecated_machines ...
> sounds reasonable, so I think we should really continue here and mark
> those as deprecated. And pc-0.10 and pc-0.11, too.

Ironically I have been using the Gumstix machines quite a lot for the SD
'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
reach the Linux userland since the kernel crashes), and plan to add SD
integration tests via Avocado.

This raises:

- What will happens if I add tests downloading running on their compiled
u-boot
(https://downloads.gumstix.com/images/angstrom/developer/2012-01-22-1750/u-boot.bin)
and the company decides to remove this old directory?
Since sometimes old open-source software are hard to rebuild with recent
compilers, should we consider to use a public storage to keep
open-source (signed) blobs we can use for integration testing?

Avocado has a 'vmimage library' which could be extended, adding support
for binary url + detached gpg signatures from some QEMU maintainers?

(I am also using old Gentoo/Debian packaged HPPA/Alpha Linux kernel for
Avocado SuperIO tests, which aren't guaranteed to stay downloadable
forever).

- Maybe I have to volunteer to update the Gumstix section from Orphan
'Odd Fixes' to keep those tests.

> Do you have some spare time to respin your patch series?

I'll make some.

Regards,

Phil.

> 
>  Thomas
>


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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)
  2018-05-08 15:47   ` Philippe Mathieu-Daudé
@ 2018-05-11 13:55     ` Eduardo Habkost
  2018-05-11 14:27       ` Cleber Rosa
  0 siblings, 1 reply; 35+ messages in thread
From: Eduardo Habkost @ 2018-05-11 13:55 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Thomas Huth, Peter Maydell, Alex Bennée, Paolo Bonzini,
	Richard Henderson, David Gibson, Alexander Graf,
	Marcel Apfelbaum, Michael S. Tsirkin, Hervé Poussineau,
	Michael Roth, qemu-devel, Cleber Rosa, avocado-devel

(CCing Cleber and avocado-devel in case they have suggestions)

On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
[...]
> Ironically I have been using the Gumstix machines quite a lot for the SD
> 'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
> reach the Linux userland since the kernel crashes), and plan to add SD
> integration tests via Avocado.
> 
> This raises:
> 
> - What will happens if I add tests downloading running on their compiled
> u-boot
> (https://downloads.gumstix.com/images/angstrom/developer/2012-01-22-1750/u-boot.bin)
> and the company decides to remove this old directory?
> Since sometimes old open-source software are hard to rebuild with recent
> compilers, should we consider to use a public storage to keep
> open-source (signed) blobs we can use for integration testing?

I think a maintained repository of images for testing would be
nice to have.  We need to be careful to comply with the license
of the software being distributed, though.

If the images are very small (like u-boot.bin above), it might be
OK to carry them in qemu.git, just like the images in pc-bios.

> 
> Avocado has a 'vmimage library' which could be extended, adding support
> for binary url + detached gpg signatures from some QEMU maintainers?

Requiring a signature makes the binaries hard to replace.  Any
specific reason to suggest gpg signatures instead of just a
(e.g.) sha256 hash?

> 
> (I am also using old Gentoo/Debian packaged HPPA/Alpha Linux kernel for
> Avocado SuperIO tests, which aren't guaranteed to stay downloadable
> forever).

Question for the Avocado folks: how this is normally handled in
avocado/avocado-vt?  Do you maintain a repository for guest
images, or you always point to their original sources?

-- 
Eduardo

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)
  2018-05-11 13:55     ` [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines) Eduardo Habkost
@ 2018-05-11 14:27       ` Cleber Rosa
  2018-05-18 18:16         ` Alistair Francis
  2019-06-17  5:17         ` [Qemu-devel] Publishing binary images for testing Philippe Mathieu-Daudé
  0 siblings, 2 replies; 35+ messages in thread
From: Cleber Rosa @ 2018-05-11 14:27 UTC (permalink / raw)
  To: Eduardo Habkost, Philippe Mathieu-Daudé
  Cc: Thomas Huth, Peter Maydell, Alex Bennée, Paolo Bonzini,
	Richard Henderson, David Gibson, Alexander Graf,
	Marcel Apfelbaum, Michael S. Tsirkin, Hervé Poussineau,
	Michael Roth, qemu-devel, avocado-devel



On 05/11/2018 09:55 AM, Eduardo Habkost wrote:
> (CCing Cleber and avocado-devel in case they have suggestions)
> 
> On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
> [...]
>> Ironically I have been using the Gumstix machines quite a lot for the SD
>> 'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
>> reach the Linux userland since the kernel crashes), and plan to add SD
>> integration tests via Avocado.
>>
>> This raises:
>>
>> - What will happens if I add tests downloading running on their compiled
>> u-boot
>> (https://downloads.gumstix.com/images/angstrom/developer/2012-01-22-1750/u-boot.bin)
>> and the company decides to remove this old directory?
>> Since sometimes old open-source software are hard to rebuild with recent
>> compilers, should we consider to use a public storage to keep
>> open-source (signed) blobs we can use for integration testing?
> 
> I think a maintained repository of images for testing would be
> nice to have.  We need to be careful to comply with the license
> of the software being distributed, though.
> 
> If the images are very small (like u-boot.bin above), it might be
> OK to carry them in qemu.git, just like the images in pc-bios.
> 
>>
>> Avocado has a 'vmimage library' which could be extended, adding support
>> for binary url + detached gpg signatures from some QEMU maintainers?
> 
> Requiring a signature makes the binaries hard to replace.  Any
> specific reason to suggest gpg signatures instead of just a
> (e.g.) sha256 hash?
> 
>>
>> (I am also using old Gentoo/Debian packaged HPPA/Alpha Linux kernel for
>> Avocado SuperIO tests, which aren't guaranteed to stay downloadable
>> forever).
> 
> Question for the Avocado folks: how this is normally handled in
> avocado/avocado-vt?  Do you maintain a repository for guest
> images, or you always point to their original sources?
> 

For pure Avocado, the vmimage library attempts to fetch, by default, the
latest version of a guest image directly from the original sources.
Say, a Fedora image will be downloaded by default from the Fedora
servers.  Because of that, we don't pay too much attention to the
availability of specific (old?) versions of guest images.

For Avocado-VT, there are the JeOS images[1], which we keep on a test
"assets" directory.  We have a lot of storage/bandwidth availability, so
it can be used for other assets proven to be necessary for tests.

As long as distribution rights and licensing are not issues, we can
definitely use the same server for kernels, u-boot images and what not.

[1] - https://avocado-project.org/data/assets/

-- 
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]
[  7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3  ]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)
  2018-05-11 14:27       ` Cleber Rosa
@ 2018-05-18 18:16         ` Alistair Francis
  2018-05-22 16:17           ` Cleber Rosa
  2019-06-17  5:17         ` [Qemu-devel] Publishing binary images for testing Philippe Mathieu-Daudé
  1 sibling, 1 reply; 35+ messages in thread
From: Alistair Francis @ 2018-05-18 18:16 UTC (permalink / raw)
  To: Cleber Rosa
  Cc: Eduardo Habkost, Philippe Mathieu-Daudé,
	Peter Maydell, Thomas Huth, Michael S. Tsirkin,
	qemu-devel@nongnu.org Developers, Alexander Graf, Michael Roth,
	avocado-devel, Hervé Poussineau, Marcel Apfelbaum,
	Paolo Bonzini, David Gibson, Alex Bennée, Richard Henderson

On Fri, May 11, 2018 at 7:27 AM, Cleber Rosa <crosa@redhat.com> wrote:
>
>
> On 05/11/2018 09:55 AM, Eduardo Habkost wrote:
>> (CCing Cleber and avocado-devel in case they have suggestions)
>>
>> On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
>> [...]
>>> Ironically I have been using the Gumstix machines quite a lot for the SD
>>> 'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
>>> reach the Linux userland since the kernel crashes), and plan to add SD
>>> integration tests via Avocado.
>>>
>>> This raises:
>>>
>>> - What will happens if I add tests downloading running on their compiled
>>> u-boot
>>> (https://downloads.gumstix.com/images/angstrom/developer/2012-01-22-1750/u-boot.bin)
>>> and the company decides to remove this old directory?
>>> Since sometimes old open-source software are hard to rebuild with recent
>>> compilers, should we consider to use a public storage to keep
>>> open-source (signed) blobs we can use for integration testing?
>>
>> I think a maintained repository of images for testing would be
>> nice to have.  We need to be careful to comply with the license
>> of the software being distributed, though.
>>
>> If the images are very small (like u-boot.bin above), it might be
>> OK to carry them in qemu.git, just like the images in pc-bios.
>>
>>>
>>> Avocado has a 'vmimage library' which could be extended, adding support
>>> for binary url + detached gpg signatures from some QEMU maintainers?
>>
>> Requiring a signature makes the binaries hard to replace.  Any
>> specific reason to suggest gpg signatures instead of just a
>> (e.g.) sha256 hash?
>>
>>>
>>> (I am also using old Gentoo/Debian packaged HPPA/Alpha Linux kernel for
>>> Avocado SuperIO tests, which aren't guaranteed to stay downloadable
>>> forever).
>>
>> Question for the Avocado folks: how this is normally handled in
>> avocado/avocado-vt?  Do you maintain a repository for guest
>> images, or you always point to their original sources?
>>
>
> For pure Avocado, the vmimage library attempts to fetch, by default, the
> latest version of a guest image directly from the original sources.
> Say, a Fedora image will be downloaded by default from the Fedora
> servers.  Because of that, we don't pay too much attention to the
> availability of specific (old?) versions of guest images.
>
> For Avocado-VT, there are the JeOS images[1], which we keep on a test
> "assets" directory.  We have a lot of storage/bandwidth availability, so
> it can be used for other assets proven to be necessary for tests.
>
> As long as distribution rights and licensing are not issues, we can
> definitely use the same server for kernels, u-boot images and what not.
>
> [1] - https://avocado-project.org/data/assets/

Is it possible to add something to the landing page at
https://avocado-project.org ?

The Palo Alto Network routers block the avocado-project.org page as
they classify it as blank. Something on the root URL would help fix
this.

Alistair

>
> --
> Cleber Rosa
> [ Sr Software Engineer - Virtualization Team - Red Hat ]
> [ Avocado Test Framework - avocado-framework.github.io ]
> [  7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3  ]
>

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)
  2018-05-18 18:16         ` Alistair Francis
@ 2018-05-22 16:17           ` Cleber Rosa
  2018-05-22 16:34             ` Alistair Francis
  0 siblings, 1 reply; 35+ messages in thread
From: Cleber Rosa @ 2018-05-22 16:17 UTC (permalink / raw)
  To: Alistair Francis
  Cc: Peter Maydell, Thomas Huth, Eduardo Habkost, Michael S. Tsirkin,
	qemu-devel@nongnu.org Developers, Philippe Mathieu-Daudé,
	Alexander Graf, avocado-devel, Hervé Poussineau,
	Marcel Apfelbaum, Paolo Bonzini, Richard Henderson,
	Alex Bennée, Michael Roth, David Gibson



On 05/18/2018 02:16 PM, Alistair Francis wrote:
> On Fri, May 11, 2018 at 7:27 AM, Cleber Rosa <crosa@redhat.com> wrote:
>>
>>
>> On 05/11/2018 09:55 AM, Eduardo Habkost wrote:
>>> (CCing Cleber and avocado-devel in case they have suggestions)
>>>
>>> On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
>>> [...]
>>>> Ironically I have been using the Gumstix machines quite a lot for the SD
>>>> 'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
>>>> reach the Linux userland since the kernel crashes), and plan to add SD
>>>> integration tests via Avocado.
>>>>
>>>> This raises:
>>>>
>>>> - What will happens if I add tests downloading running on their compiled
>>>> u-boot
>>>> (https://downloads.gumstix.com/images/angstrom/developer/2012-01-22-1750/u-boot.bin)
>>>> and the company decides to remove this old directory?
>>>> Since sometimes old open-source software are hard to rebuild with recent
>>>> compilers, should we consider to use a public storage to keep
>>>> open-source (signed) blobs we can use for integration testing?
>>>
>>> I think a maintained repository of images for testing would be
>>> nice to have.  We need to be careful to comply with the license
>>> of the software being distributed, though.
>>>
>>> If the images are very small (like u-boot.bin above), it might be
>>> OK to carry them in qemu.git, just like the images in pc-bios.
>>>
>>>>
>>>> Avocado has a 'vmimage library' which could be extended, adding support
>>>> for binary url + detached gpg signatures from some QEMU maintainers?
>>>
>>> Requiring a signature makes the binaries hard to replace.  Any
>>> specific reason to suggest gpg signatures instead of just a
>>> (e.g.) sha256 hash?
>>>
>>>>
>>>> (I am also using old Gentoo/Debian packaged HPPA/Alpha Linux kernel for
>>>> Avocado SuperIO tests, which aren't guaranteed to stay downloadable
>>>> forever).
>>>
>>> Question for the Avocado folks: how this is normally handled in
>>> avocado/avocado-vt?  Do you maintain a repository for guest
>>> images, or you always point to their original sources?
>>>
>>
>> For pure Avocado, the vmimage library attempts to fetch, by default, the
>> latest version of a guest image directly from the original sources.
>> Say, a Fedora image will be downloaded by default from the Fedora
>> servers.  Because of that, we don't pay too much attention to the
>> availability of specific (old?) versions of guest images.
>>
>> For Avocado-VT, there are the JeOS images[1], which we keep on a test
>> "assets" directory.  We have a lot of storage/bandwidth availability, so
>> it can be used for other assets proven to be necessary for tests.
>>
>> As long as distribution rights and licensing are not issues, we can
>> definitely use the same server for kernels, u-boot images and what not.
>>
>> [1] - https://avocado-project.org/data/assets/
> 
> Is it possible to add something to the landing page at
> https://avocado-project.org ?
> 

Done!
- Cleber.

> The Palo Alto Network routers block the avocado-project.org page as
> they classify it as blank. Something on the root URL would help fix
> this.
> 
> Alistair
> 

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)
  2018-05-22 16:17           ` Cleber Rosa
@ 2018-05-22 16:34             ` Alistair Francis
  0 siblings, 0 replies; 35+ messages in thread
From: Alistair Francis @ 2018-05-22 16:34 UTC (permalink / raw)
  To: Cleber Rosa
  Cc: Peter Maydell, Thomas Huth, Eduardo Habkost, Michael S. Tsirkin,
	qemu-devel@nongnu.org Developers, Philippe Mathieu-Daudé,
	Alexander Graf, avocado-devel, Hervé Poussineau,
	Marcel Apfelbaum, Paolo Bonzini, Richard Henderson,
	Alex Bennée, Michael Roth, David Gibson

On Tue, May 22, 2018 at 9:17 AM, Cleber Rosa <crosa@redhat.com> wrote:
>
>
> On 05/18/2018 02:16 PM, Alistair Francis wrote:
>> On Fri, May 11, 2018 at 7:27 AM, Cleber Rosa <crosa@redhat.com> wrote:
>>>
>>>
>>> On 05/11/2018 09:55 AM, Eduardo Habkost wrote:
>>>> (CCing Cleber and avocado-devel in case they have suggestions)
>>>>
>>>> On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
>>>> [...]
>>>>> Ironically I have been using the Gumstix machines quite a lot for the SD
>>>>> 'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
>>>>> reach the Linux userland since the kernel crashes), and plan to add SD
>>>>> integration tests via Avocado.
>>>>>
>>>>> This raises:
>>>>>
>>>>> - What will happens if I add tests downloading running on their compiled
>>>>> u-boot
>>>>> (https://downloads.gumstix.com/images/angstrom/developer/2012-01-22-1750/u-boot.bin)
>>>>> and the company decides to remove this old directory?
>>>>> Since sometimes old open-source software are hard to rebuild with recent
>>>>> compilers, should we consider to use a public storage to keep
>>>>> open-source (signed) blobs we can use for integration testing?
>>>>
>>>> I think a maintained repository of images for testing would be
>>>> nice to have.  We need to be careful to comply with the license
>>>> of the software being distributed, though.
>>>>
>>>> If the images are very small (like u-boot.bin above), it might be
>>>> OK to carry them in qemu.git, just like the images in pc-bios.
>>>>
>>>>>
>>>>> Avocado has a 'vmimage library' which could be extended, adding support
>>>>> for binary url + detached gpg signatures from some QEMU maintainers?
>>>>
>>>> Requiring a signature makes the binaries hard to replace.  Any
>>>> specific reason to suggest gpg signatures instead of just a
>>>> (e.g.) sha256 hash?
>>>>
>>>>>
>>>>> (I am also using old Gentoo/Debian packaged HPPA/Alpha Linux kernel for
>>>>> Avocado SuperIO tests, which aren't guaranteed to stay downloadable
>>>>> forever).
>>>>
>>>> Question for the Avocado folks: how this is normally handled in
>>>> avocado/avocado-vt?  Do you maintain a repository for guest
>>>> images, or you always point to their original sources?
>>>>
>>>
>>> For pure Avocado, the vmimage library attempts to fetch, by default, the
>>> latest version of a guest image directly from the original sources.
>>> Say, a Fedora image will be downloaded by default from the Fedora
>>> servers.  Because of that, we don't pay too much attention to the
>>> availability of specific (old?) versions of guest images.
>>>
>>> For Avocado-VT, there are the JeOS images[1], which we keep on a test
>>> "assets" directory.  We have a lot of storage/bandwidth availability, so
>>> it can be used for other assets proven to be necessary for tests.
>>>
>>> As long as distribution rights and licensing are not issues, we can
>>> definitely use the same server for kernels, u-boot images and what not.
>>>
>>> [1] - https://avocado-project.org/data/assets/
>>
>> Is it possible to add something to the landing page at
>> https://avocado-project.org ?
>>
>
> Done!

Awesome! It looks good and this should help everyone behind a proxy.

Alistair

> - Cleber.
>
>> The Palo Alto Network routers block the avocado-project.org page as
>> they classify it as blank. Something on the root URL would help fix
>> this.
>>
>> Alistair
>>

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] Publishing binary images for testing
  2018-05-11 14:27       ` Cleber Rosa
  2018-05-18 18:16         ` Alistair Francis
@ 2019-06-17  5:17         ` Philippe Mathieu-Daudé
  2019-08-16 10:51           ` Philippe Mathieu-Daudé
  1 sibling, 1 reply; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-06-17  5:17 UTC (permalink / raw)
  To: Cleber Rosa, Eduardo Habkost
  Cc: Peter Maydell, Thomas Huth, Michael S. Tsirkin, Michael Roth,
	qemu-devel, Alexander Graf, avocado-devel, Hervé Poussineau,
	Marcel Apfelbaum, Paolo Bonzini, Richard Henderson,
	Alex Bennée, David Gibson

Hi Cleber,

On 5/11/18 4:27 PM, Cleber Rosa wrote:
> On 05/11/2018 09:55 AM, Eduardo Habkost wrote:
>> (CCing Cleber and avocado-devel in case they have suggestions)
>>
>> On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
>> [...]
>>> Ironically I have been using the Gumstix machines quite a lot for the SD
>>> 'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
>>> reach the Linux userland since the kernel crashes), and plan to add SD
>>> integration tests via Avocado.
>>>
>>> This raises:
>>>
>>> - What will happens if I add tests downloading running on their compiled
>>> u-boot
>>> (https://downloads.gumstix.com/images/angstrom/developer/2012-01-22-1750/u-boot.bin)
>>> and the company decides to remove this old directory?
>>> Since sometimes old open-source software are hard to rebuild with recent
>>> compilers, should we consider to use a public storage to keep
>>> open-source (signed) blobs we can use for integration testing?
>>
>> I think a maintained repository of images for testing would be
>> nice to have.  We need to be careful to comply with the license
>> of the software being distributed, though.
>>
>> If the images are very small (like u-boot.bin above), it might be
>> OK to carry them in qemu.git, just like the images in pc-bios.
>>
>>>
>>> Avocado has a 'vmimage library' which could be extended, adding support
>>> for binary url + detached gpg signatures from some QEMU maintainers?
>>
>> Requiring a signature makes the binaries hard to replace.  Any
>> specific reason to suggest gpg signatures instead of just a
>> (e.g.) sha256 hash?
>>
>>>
>>> (I am also using old Gentoo/Debian packaged HPPA/Alpha Linux kernel for
>>> Avocado SuperIO tests, which aren't guaranteed to stay downloadable
>>> forever).
>>
>> Question for the Avocado folks: how this is normally handled in
>> avocado/avocado-vt?  Do you maintain a repository for guest
>> images, or you always point to their original sources?
>>
> 
> For pure Avocado, the vmimage library attempts to fetch, by default, the
> latest version of a guest image directly from the original sources.
> Say, a Fedora image will be downloaded by default from the Fedora
> servers.  Because of that, we don't pay too much attention to the
> availability of specific (old?) versions of guest images.
> 
> For Avocado-VT, there are the JeOS images[1], which we keep on a test
> "assets" directory.  We have a lot of storage/bandwidth availability, so
> it can be used for other assets proven to be necessary for tests.
> 
> As long as distribution rights and licensing are not issues, we can
> definitely use the same server for kernels, u-boot images and what not.
> 
> [1] - https://avocado-project.org/data/assets/

1/ How do we check for distribution rights?

Is it OK for:
- a Debian/Fedora image
- a compiled Linux kernel (for a Debian/Fedora release)

2/ Who to ask to add files to this assets directory?

3/ Can we use a 'webarchive' directory structure?

Such /site/date/original_site_path/file

4/ What are the chances that this website disappears? :S

(Someone has to pay for it, and the bandwidth...)

Thanks,

Phil.


^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] Publishing binary images for testing
  2019-06-17  5:17         ` [Qemu-devel] Publishing binary images for testing Philippe Mathieu-Daudé
@ 2019-08-16 10:51           ` Philippe Mathieu-Daudé
  2019-08-19 13:10             ` Cleber Rosa
  0 siblings, 1 reply; 35+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-08-16 10:51 UTC (permalink / raw)
  To: Cleber Rosa, Eduardo Habkost
  Cc: Peter Maydell, Thomas Huth, Michael S. Tsirkin, Michael Roth,
	qemu-devel, avocado-devel, Hervé Poussineau,
	Marcel Apfelbaum, Paolo Bonzini, Richard Henderson,
	Alex Bennée, David Gibson

ping? :)

On 6/17/19 7:17 AM, Philippe Mathieu-Daudé wrote:
> Hi Cleber,
> 
> On 5/11/18 4:27 PM, Cleber Rosa wrote:
>> On 05/11/2018 09:55 AM, Eduardo Habkost wrote:
>>> (CCing Cleber and avocado-devel in case they have suggestions)
>>>
>>> On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
>>> [...]
>>>> Ironically I have been using the Gumstix machines quite a lot for the SD
>>>> 'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
>>>> reach the Linux userland since the kernel crashes), and plan to add SD
>>>> integration tests via Avocado.
>>>>
>>>> This raises:
>>>>
>>>> - What will happens if I add tests downloading running on their compiled
>>>> u-boot
>>>> (https://downloads.gumstix.com/images/angstrom/developer/2012-01-22-1750/u-boot.bin)
>>>> and the company decides to remove this old directory?
>>>> Since sometimes old open-source software are hard to rebuild with recent
>>>> compilers, should we consider to use a public storage to keep
>>>> open-source (signed) blobs we can use for integration testing?
>>>
>>> I think a maintained repository of images for testing would be
>>> nice to have.  We need to be careful to comply with the license
>>> of the software being distributed, though.
>>>
>>> If the images are very small (like u-boot.bin above), it might be
>>> OK to carry them in qemu.git, just like the images in pc-bios.
>>>
>>>>
>>>> Avocado has a 'vmimage library' which could be extended, adding support
>>>> for binary url + detached gpg signatures from some QEMU maintainers?
>>>
>>> Requiring a signature makes the binaries hard to replace.  Any
>>> specific reason to suggest gpg signatures instead of just a
>>> (e.g.) sha256 hash?
>>>
>>>>
>>>> (I am also using old Gentoo/Debian packaged HPPA/Alpha Linux kernel for
>>>> Avocado SuperIO tests, which aren't guaranteed to stay downloadable
>>>> forever).
>>>
>>> Question for the Avocado folks: how this is normally handled in
>>> avocado/avocado-vt?  Do you maintain a repository for guest
>>> images, or you always point to their original sources?
>>>
>>
>> For pure Avocado, the vmimage library attempts to fetch, by default, the
>> latest version of a guest image directly from the original sources.
>> Say, a Fedora image will be downloaded by default from the Fedora
>> servers.  Because of that, we don't pay too much attention to the
>> availability of specific (old?) versions of guest images.
>>
>> For Avocado-VT, there are the JeOS images[1], which we keep on a test
>> "assets" directory.  We have a lot of storage/bandwidth availability, so
>> it can be used for other assets proven to be necessary for tests.
>>
>> As long as distribution rights and licensing are not issues, we can
>> definitely use the same server for kernels, u-boot images and what not.
>>
>> [1] - https://avocado-project.org/data/assets/
> 
> 1/ How do we check for distribution rights?
> 
> Is it OK for:
> - a Debian/Fedora image
> - a compiled Linux kernel (for a Debian/Fedora release)
> 
> 2/ Who to ask to add files to this assets directory?
> 
> 3/ Can we use a 'webarchive' directory structure?
> 
> Such /site/date/original_site_path/file
> 
> 4/ What are the chances that this website disappears? :S
> 
> (Someone has to pay for it, and the bandwidth...)
> 
> Thanks,
> 
> Phil.


^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: [Qemu-devel] Publishing binary images for testing
  2019-08-16 10:51           ` Philippe Mathieu-Daudé
@ 2019-08-19 13:10             ` Cleber Rosa
  0 siblings, 0 replies; 35+ messages in thread
From: Cleber Rosa @ 2019-08-19 13:10 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Peter Maydell, Thomas Huth, Eduardo Habkost, Michael S. Tsirkin,
	qemu-devel, Michael Roth, avocado-devel, Hervé Poussineau,
	Marcel Apfelbaum, Paolo Bonzini, Richard Henderson,
	Alex Bennée, David Gibson

On Fri, Aug 16, 2019 at 12:51:06PM +0200, Philippe Mathieu-Daudé wrote:
> ping? :)
> 
> On 6/17/19 7:17 AM, Philippe Mathieu-Daudé wrote:
> > Hi Cleber,
> > 
> > On 5/11/18 4:27 PM, Cleber Rosa wrote:
> >> On 05/11/2018 09:55 AM, Eduardo Habkost wrote:
> >>> (CCing Cleber and avocado-devel in case they have suggestions)
> >>>
> >>> On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
> >>> [...]
> >>>> Ironically I have been using the Gumstix machines quite a lot for the SD
> >>>> 'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
> >>>> reach the Linux userland since the kernel crashes), and plan to add SD
> >>>> integration tests via Avocado.
> >>>>
> >>>> This raises:
> >>>>
> >>>> - What will happens if I add tests downloading running on their compiled
> >>>> u-boot
> >>>> (https://downloads.gumstix.com/images/angstrom/developer/2012-01-22-1750/u-boot.bin)
> >>>> and the company decides to remove this old directory?
> >>>> Since sometimes old open-source software are hard to rebuild with recent
> >>>> compilers, should we consider to use a public storage to keep
> >>>> open-source (signed) blobs we can use for integration testing?
> >>>
> >>> I think a maintained repository of images for testing would be
> >>> nice to have.  We need to be careful to comply with the license
> >>> of the software being distributed, though.
> >>>
> >>> If the images are very small (like u-boot.bin above), it might be
> >>> OK to carry them in qemu.git, just like the images in pc-bios.
> >>>
> >>>>
> >>>> Avocado has a 'vmimage library' which could be extended, adding support
> >>>> for binary url + detached gpg signatures from some QEMU maintainers?

Yes, although I believe a stronger distinction between the images
originally targeted by avocado.utils.vmimage and those other images
should probably exist.  One of the reasons that make me think so is
that the images obtained through vmimage *should* be configurable by
the accompanying avocado.utils.cloudinit library.

> >>>
> >>> Requiring a signature makes the binaries hard to replace.  Any
> >>> specific reason to suggest gpg signatures instead of just a
> >>> (e.g.) sha256 hash?
> >>>
> >>>>
> >>>> (I am also using old Gentoo/Debian packaged HPPA/Alpha Linux kernel for
> >>>> Avocado SuperIO tests, which aren't guaranteed to stay downloadable
> >>>> forever).
> >>>
> >>> Question for the Avocado folks: how this is normally handled in
> >>> avocado/avocado-vt?  Do you maintain a repository for guest
> >>> images, or you always point to their original sources?
> >>>
> >>
> >> For pure Avocado, the vmimage library attempts to fetch, by default, the
> >> latest version of a guest image directly from the original sources.
> >> Say, a Fedora image will be downloaded by default from the Fedora
> >> servers.  Because of that, we don't pay too much attention to the
> >> availability of specific (old?) versions of guest images.
> >>
> >> For Avocado-VT, there are the JeOS images[1], which we keep on a test
> >> "assets" directory.  We have a lot of storage/bandwidth availability, so
> >> it can be used for other assets proven to be necessary for tests.
> >>
> >> As long as distribution rights and licensing are not issues, we can
> >> definitely use the same server for kernels, u-boot images and what not.
> >>
> >> [1] - https://avocado-project.org/data/assets/
> > 
> > 1/ How do we check for distribution rights?
> > 
> > Is it OK for:
> > - a Debian/Fedora image
> > - a compiled Linux kernel (for a Debian/Fedora release)
> >

I think released images are just fine.

FIY, with regards to custom iamges: the Avocado-VT JeOS images are
based on Fedora, and can be recreated with the kickstart files that
are also in-tree.  Making the custom binary file reproducible is,
AFAICT good enough.

> > 2/ Who to ask to add files to this assets directory?
> >

I'd be happy to setup a secure upload mechanism, say, ftp+ssl, so that
"image maintainers" can upload new images.

> > 3/ Can we use a 'webarchive' directory structure?
> > 
> > Such /site/date/original_site_path/file
> >

I don't see why not.

> > 4/ What are the chances that this website disappears? :S
> > 
> > (Someone has to pay for it, and the bandwidth...)

Of course the best scenario would be to rely on some bigger
institution, say an University decides to host this archive of images,
and others decide to mirror them.  Until then, if it's decided to push
forward the use of the "avocado-project.org" site, the chances of it
going away are basically if I fail to have $5/month to keep it
running, so hopefully (I mean it) this won't be an issue :)

And thans for the ping, although I was really in need of a brick thrown
at my head to wake me up on this thread! :)

- Cleber.

> > 
> > Thanks,
> > 
> > Phil.


^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, back to index

Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-08  2:28 [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Philippe Mathieu-Daudé
2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property Philippe Mathieu-Daudé
2017-11-08 10:23   ` Thomas Huth
2017-11-08 10:27     ` Daniel P. Berrange
2017-11-08 20:29   ` Eduardo Habkost
2018-01-22  2:10     ` Philippe Mathieu-Daudé
2018-01-22  6:21       ` Thomas Huth
2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 2/6] hw/arm: deprecate the EP108 board Philippe Mathieu-Daudé
2017-11-08  9:17   ` Daniel P. Berrange
2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 3/6] hw/arm: deprecate the Gumstix boards Philippe Mathieu-Daudé
2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 4/6] hw/ppc: deprecate the PReP machine Philippe Mathieu-Daudé
2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines Philippe Mathieu-Daudé
2017-11-08  2:48   ` Alexey Kardashevskiy
2017-11-08  3:28     ` Philippe Mathieu-Daudé
2017-11-08  9:13       ` Daniel P. Berrange
2017-11-08 10:43         ` Thomas Huth
2017-11-08  9:16   ` Daniel P. Berrange
2017-11-08 10:15     ` Thomas Huth
2017-11-08 11:36   ` Thomas Huth
2017-11-08  2:28 ` [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine Philippe Mathieu-Daudé
2017-11-08  3:29   ` Philippe Mathieu-Daudé
2017-11-08  9:09   ` Daniel P. Berrange
2017-11-08  9:44     ` Gerd Hoffmann
2017-11-08 10:05       ` Thomas Huth
2017-11-08  9:10 ` [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Daniel P. Berrange
2018-05-04 17:15 ` Thomas Huth
2018-05-08 15:47   ` Philippe Mathieu-Daudé
2018-05-11 13:55     ` [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines) Eduardo Habkost
2018-05-11 14:27       ` Cleber Rosa
2018-05-18 18:16         ` Alistair Francis
2018-05-22 16:17           ` Cleber Rosa
2018-05-22 16:34             ` Alistair Francis
2019-06-17  5:17         ` [Qemu-devel] Publishing binary images for testing Philippe Mathieu-Daudé
2019-08-16 10:51           ` Philippe Mathieu-Daudé
2019-08-19 13:10             ` Cleber Rosa

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git