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

[Eduardo Habkost]

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?

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


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