Re: [PATCH 5/5] include: Move hardware version declarations to new qemu/hw-version.h

[Philippe Mathieu-Daudé]

On 9/2/22 10:25, Peter Maydell wrote:
> On Wed, 9 Feb 2022 at 09:20, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> > On 8/2/22 21:08, Peter Maydell wrote:
> > > The "hardware version" machinery (qemu_set_hw_version(),
> > > qemu_hw_version(), and the QEMU_HW_VERSION define) is used by fewer
> > > than 10 files.  Move it out from osdep.h into a new
> > > qemu/hw-version.h.
> > >
> > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> > > ---
> > >    include/qemu/hw-version.h | 27 +++++++++++++++++++++++++++
> > >    include/qemu/osdep.h      | 16 ----------------
> > >    hw/arm/nseries.c          |  1 +
> > >    hw/ide/core.c             |  1 +
> > >    hw/scsi/megasas.c         |  1 +
> > >    hw/scsi/scsi-bus.c        |  1 +
> > >    hw/scsi/scsi-disk.c       |  1 +
> > >    softmmu/vl.c              |  1 +
> > >    target/i386/cpu.c         |  1 +
> > >    target/s390x/cpu_models.c |  1 +
> > >    util/osdep.c              |  1 +
> > >    11 files changed, 36 insertions(+), 16 deletions(-)
> > >    create mode 100644 include/qemu/hw-version.h

> > > +/*
> > > + * Starting on QEMU 2.5, qemu_hw_version() returns "2.5+" by default
> > > + * instead of QEMU_VERSION, so setting hw_version on MachineClass
> > > + * is no longer mandatory.
> > > + *
> > > + * Do NOT change this string, or it will break compatibility on all
> > > + * machine classes that don't set hw_version.
> > > + */
> > > +#define QEMU_HW_VERSION "2.5+"
> > > +
> > > +/* QEMU "hardware version" setting. Used to replace code that exposed
> > > + * QEMU_VERSION to guests in the past and need to keep compatibility.
> > > + * Do not use qemu_hw_version() in new code.
> >
> > Can you include the "legacy" word somewhere in the include path?
>
> I'm not completely convinced that (a) we have a clear idea of
> what of our APIs are legacy and what are not or (b) that we could
> coherently move the 'legacy' ones into separate files.
> If you want to propose something like that as an RFC, I don't
> 100% object to it, but I don't want to do a very small subset
> of that as part of what is really just a "get stuff out of osdep"
> series.

OK, thanks.