On Tue, Nov 06, 2018 at 11:23:31AM +0100, Gerd Hoffmann wrote: > Indicates support state for something (device, backend, subsystem, ...) > in qemu. Add QemuSupportState field to ObjectClass. Add some support > code. > > TODO: wire up to qom-list-types > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> > --- [...] > +## > +# @SupportState: > +# > +# Indicate Support level of qemu devices, backends, subsystems, ... > +# > +# @unspecified: not specified (zero-initialized). > +# > +# @experimental: in development, can be unstable or incomplete.
People reading this document would ask: what would appear on MAINTAINERS if SupportState is `experimental`? > +# > +# @supported: works stable and is fully supported. > +# (supported + maintained in MAINTAINERS). > +# > +# @unsupported: should work, support is weak or not present. > +# (odd-fixes + orphan in MAINTAINERS). What's the difference in practice between unsupported and experimental? > +# > +# @obsolete: is obsolete, still present for compatibility reasons, > +# will likely be removed at some point in the future. > +# Not deprecated (yet). > +# (obsolete in MAINTAINERS). > +# > +# @deprecated: is deprecated, according to qemu deprecation policy. I believe we want to differentiate "deprecated, but still safe to use in production if you have a migration plan" from "deprecated, and also unstable and unsafe for production". I expect enterprise distributions to have a strict policy of not allowing unsupported and experimental devices to be enabled, but still allow deprecated devices to be enabled (but only if they are stable/supported). -- Eduardo
