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
