On Wed, 9 Feb 2022 at 09:20, Philippe Mathieu-Daudé <f4...@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.mayd...@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 > > > > diff --git a/include/qemu/hw-version.h b/include/qemu/hw-version.h > > new file mode 100644 > > index 00000000000..730a8c904d9 > > --- /dev/null > > +++ b/include/qemu/hw-version.h > > @@ -0,0 +1,27 @@ > > +/* > > + * QEMU "hardware version" machinery > > + * > > + * This work is licensed under the terms of the GNU GPL, version 2 or > > later. > > + * See the COPYING file in the top-level directory. > > + */ > > +#ifndef QEMU_HW_VERSION_H > > +#define 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. thanks -- PMM
