[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gerd Hoffmann
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 1/4] add QemuSupportState
Date: Mon, 5 Nov 2018 08:30:28 +0100
User-agent: NeoMutt/20180716


> > - 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.

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]