[Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines

[Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines

[Philippe Mathieu-Daudé]

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

[Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property

[Philippe Mathieu-Daudé]

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

[Qemu-devel] [RFC PATCH 2/6] hw/arm: deprecate the EP108 board

[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

[Qemu-devel] [RFC PATCH 3/6] hw/arm: deprecate the Gumstix boards

[Philippe Mathieu-Daudé]

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

[Qemu-devel] [RFC PATCH 4/6] hw/ppc: deprecate the PReP machine

[Philippe Mathieu-Daudé]

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

[Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines

[Philippe Mathieu-Daudé]

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

[Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine

[Philippe Mathieu-Daudé]

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

Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines

[Alexey Kardashevskiy]

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

Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines

[Philippe Mathieu-Daudé]

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

Re: [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine

[Philippe Mathieu-Daudé]

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

Re: [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine

[Daniel P. Berrange]

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

Re: [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines

[Daniel P. Berrange]

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

Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines

[Daniel P. Berrange]

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

Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines

[Daniel P. Berrange]

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

Re: [Qemu-devel] [RFC PATCH 2/6] hw/arm: deprecate the EP108 board

[Daniel P. Berrange]

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

Re: [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine

[Gerd Hoffmann]

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

Re: [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine

[Thomas Huth]

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

Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines

[Thomas Huth]

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

Re: [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property

[Thomas Huth]

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

Re: [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property

[Daniel P. Berrange]

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

Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines

[Thomas Huth]

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

Re: [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines

[Thomas Huth]

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

Re: [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property

[Eduardo Habkost]

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

Re: [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property

[Philippe Mathieu-Daudé]

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.

Re: [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property

[Thomas Huth]

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

Re: [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines

[Thomas Huth]

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

Re: [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines

[Philippe Mathieu-Daudé]

[-- 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 --]

[Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)

[Eduardo Habkost]

(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

Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)

[Cleber Rosa]

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  ]

Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)

[Alistair Francis]

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

Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)

[Cleber Rosa]

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
> 

Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)

[Alistair Francis]

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

Re: [Qemu-devel] Publishing binary images for testing

[Philippe Mathieu-Daudé]

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.

Re: [Qemu-devel] Publishing binary images for testing

[Philippe Mathieu-Daudé]

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.

Re: [Qemu-devel] Publishing binary images for testing

[Cleber Rosa]

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.