On Tue, Apr 29, 2025 at 04:30:56PM +0200, Thomas Huth wrote:
> On 29/04/2025 15.15, Daniel P. Berrangé wrote:
> > This reverts commit c9fd2d9a48ee3c195cf83cc611b87b09f02f0013.
> >
> > When we introduced the specialized machine type deprecation policy, we
> > allow automatic deprecation to take effect immediately, but blocked the
> > automatic deletion of machine types for 2 releases. This ensured we
> > complied with the historical deprecation policy during the transition
> > window. Startnig with the 10.1.0 dev cycle, the old machine types would
>
> typo: Startnig
>
> > be candidates for removal under both the old and new deprecation
> > policies.
> >
> > Thus we can now enable automatic deletion of old machine types, which
> > takes effect by skipping the QOM type registration. This prevents the
> > machine types being listed with '-machine help', and blocks their
> > creation. The actual code can be purged at a convenient time of the
> > maintainer's choosing.
> >
> > In the case of the x86_64 target, this change results in the blocking
> > of the following machine types:
> >
> > pc-i440fx-4.0 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-i440fx-3.1 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-i440fx-3.0 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-i440fx-2.9 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-i440fx-2.8 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-i440fx-2.7 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-i440fx-2.6 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-i440fx-2.5 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-i440fx-2.4 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-i440fx-2.12 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-i440fx-2.11 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-i440fx-2.10 Standard PC (i440FX + PIIX, 1996) (deprecated)
> > pc-q35-4.0.1 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-4.0 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-3.1 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-3.0 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-2.9 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-2.8 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-2.7 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-2.6 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-2.5 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-2.4 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-2.12 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-2.11 Standard PC (Q35 + ICH9, 2009) (deprecated)
> > pc-q35-2.10 Standard PC (Q35 + ICH9, 2009) (deprecated)
> >
> > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
> > ---
> > include/hw/boards.h | 19 +------------------
> > 1 file changed, 1 insertion(+), 18 deletions(-)
> >
> > diff --git a/include/hw/boards.h b/include/hw/boards.h
> > index 765dc8dd35..74a8e96b2e 100644
> > --- a/include/hw/boards.h
> > +++ b/include/hw/boards.h
> > @@ -719,28 +719,11 @@ struct MachineState {
> > * suitable period of time has passed, it will cause
> > * execution of the method to return, avoiding registration
> > * of the machine
> > - *
> > - * The new deprecation and deletion policy for versioned
> > - * machine types was introduced in QEMU 9.1.0.
> > - *
> > - * Under the new policy a number of old machine types (any
> > - * prior to 2.12) would be liable for immediate deletion
> > - * which would be a violation of our historical deprecation
> > - * and removal policy
> > - *
> > - * Thus deletions are temporarily gated on existance of
> > - * the env variable "QEMU_DELETE_MACHINES" / QEMU version
> > - * number >= 10.1.0. This gate can be deleted in the 10.1.0
> > - * dev cycle
> > */
> > #define MACHINE_VER_DELETION(...) \
> > do { \
> > if (MACHINE_VER_SHOULD_DELETE(__VA_ARGS__)) { \
> > - if (getenv("QEMU_DELETE_MACHINES") || \
> > - QEMU_VERSION_MAJOR > 10 || (QEMU_VERSION_MAJOR == 10 && \
> > - QEMU_VERSION_MINOR >= 1)) { \
> > - return; \
> > - } \
> > + return; \
>
> I wonder whether we might want to have it the other way round now instead,
> so that we could re-activate the dead machines in case a certain environment
> variable (QEMU_ZOMBI_MACHINES) is set? Anyway, just an idea, not sure
> whether it's a good one. So for this patch:
Well we should have followup patch(s) to actually delete the now unused
machine code, so ideally there will be no machines that could be
re-activated.
>
> Reviewed-by: Thomas Huth <th...@redhat.com>
>
>
> > } \
> > } while (0)
>
With 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 :|
