Re: [Qemu-ppc] [Qemu-devel] [PATCH 1/4] add QemuSupportState

[Gerd Hoffmann]

On Mon, Nov 05, 2018 at 11:49:40AM -0200, Eduardo Habkost wrote:
> On Mon, Nov 05, 2018 at 08:30:28AM +0100, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > > - Maintainers can deprecate stuffs
> > > > - Orphan code can become Supported
> > > > - Once scheduled for removal, there is no way back
> > > > - 'Unknown' seems pretty similar to 'Orphan'.
> > > 
> > > I'm still worried that the supported/unsupported distinction may
> > > cause unnecessary hassle for every downstream distributor of
> > > QEMU.  Do we really have a need to differentiate supported vs
> > > unsupported device types at runtime?
> > 
> > How do you suggest to handle cirrus then?
> > 
> > Trying to deprecate it outright didn't work very well, kind of
> > understandable given that it has been the default for a long time.
> > 
> > So I think we have to mark cirrus as "obsolete", printing a message for
> > the users that they should switch to another display device (stdvga for
> > example), but keep it working for a while.
> > 
> > There are also a bunch of devices where I suspect they are not used much
> > if at all.  All those isa sound cards for example.  Playing old DOS
> > games is pretty much the only use case I can think of.  But I'm
> > wondering whenever people actually use qemu for that.  There are
> > alternatives which probably handle that use case better, i.e. dosbox.
> > 
> > Simliar case is bluetooth emulation.  I can't remember having seen any
> > message or patch for years.
> > 
> > Tagging such devices as "obsolete", with a message asking people to
> > report their use cases, might help figuring if and why those devices are
> > used in the wild.
> 
> Thanks for the more detailed description of the use case you have
> in mind.  It makes sense to me.
> 
> Now, I have two questions:
> 
> 1) What's more important: telling the user they are relying on an
>    obsolete feature, or that they are relying on an unsupported
>    feature?  What exactly is the difference?

Maybe we should pick up the suggestion (by danp I think) to have two
states, one describing the support level, and one for usage hints (i.e
"you should not use this for performance reasons, unless you run a guest
older than a decade").

> 2) Do we really need to differentiate between "obsolete" and
>    "deprecated" features?  What exactly is the difference?

"deprecated" - is on deprecation schedule according to qemu deprecation
               policy (remove after two releases).
"obsolete"   - not (yet) on deprecation schedule.

> In either case, I believe a simple supported/obsolete (or
> supported/unsupported) distinction is probably going to be more
> useful than a detailed
> supported/maintained/odd-fixes/orphan/obsolete model.
> 
> Reviewing a list of obsolete devices downstream (to decide if
> they should be still compiled in downstream) sounds doable.
> Fixing up detailed supported/maintained/odd-fixes/orphan data
> downstream sounds like unnecessary extra work.
> 
> 
> > 
> > > I'd prefer to make support/unsupported differentiation to be a
> > > build system feature (e.g. a CONFIG_UNSUPPORTED build-time
> > > option) instead of a QMP/runtime feature.
> > 
> > That would be nice too, but I think we need kbuild first, otherwise
> > it'll be pretty messy.
> 
> Agreed.
> 
> -- 
> Eduardo