On Tue, Oct 30, 2018 at 06:37:42PM +0100, Philippe Mathieu-Daudé wrote: > On 30/10/18 16:46, Cornelia Huck wrote: > > On Tue, 30 Oct 2018 15:13:45 +0100 > > Philippe Mathieu-Daudé <phi...@redhat.com> wrote: > > > > > On 30/10/18 15:00, Gerd Hoffmann wrote: > > > > On Tue, Oct 30, 2018 at 02:32:40PM +0100, Philippe Mathieu-Daudé wrote: > > > > > > +## > > > > > > +# @SupportState: > > > > > > +# > > > > > > +# Indicate Support level of qemu devices, backends, subsystems, ... > > > > > > +# > > > > > > +# Since: 3.2 > > > > > > +## > > > > > > +{ 'enum': 'SupportState', > > > > > > + 'data': [ 'unknown', > > > > > > > > > > 'unknown' is scary and should be fixed. > > > > > > > > 'unknown' maps to "0" due to being first in list, so this is what you > > > > get when it isn't explicitly set to something else. Which make sense > > > > IMHO. > > > > > > Yes, I understand in your next patch, this case won't display warning to > > > the user. > > > > > > I wanted to say "we should fix those entries in the MAINTAINERS file". > > > > I think that has been an ongoing quest for years :) > > > > > > > > > > > + 'supported', > > > > > > + 'maintained', > > > > > > + 'odd-fixes', > > > > > > > > > > All those fit in 'supported' > > > > > > + 'orphan', > > > > > > + 'obsolete', > > > > > > + 'deprecated' ] } > > > > > > > > > > And all those should appear as 'deprecated' IMHO. > > > > > > > > See minutes on deprecation discussion. Seems there is agreement we > > > > need something more finegrained than "supported" and "deprecated". > > > > > > I read again the "Minutes of KVM Forum BoF on deprecating stuff" thread > > > and don't find details on finegrains, can you point it to me? > > > > > > I think these are fine in the MAINTAINERS entries, but don't give useful > > > information to a QEMU user that is not custom to MAINTAINERS. > > > > We might squash 'supported' and 'maintained' together (as their only > > real difference is whether someone gets paid for it), but 'odd fixes' > > is different IMO (you have someone to talk to, but they don't dedicate > > much of their time to it.) > > > > > > > > As a user I'd expect anything not "supported" to be eventually > > > "deprecated". > > > > But there are differences: > > - 'orphan' - nobody is looking after it; should become 'deprecated' if > > nobody steps up, but may move to one of the 'someone looks after it' > > states > > - 'obsolete' - don't use this; should move to 'deprecated' once a > > replacement is ready (or it is not needed anymore) > > - 'deprecated' - on the removal schedule; has not necessarily been in > > 'orphan' or 'obsolete' before > > OK! > > If I understand correctly, we have this 'state machine': > > Supported Unsupported Deprecated > > (someone to talk) (nobody to talk) (scheduled for removal) > +--------------+ +------------+ +--------------+ > | S:Maintained | | S:Unknown | | | > | | | | | | > | S:Supported + <---> | S:Orphan +----> | S:Deprecated +----> Removed > | | | | | | > | S:Odd Fixes | | S:Obsolete | | | > +------+-------+ +------------+ +--------------+ > | ^ > | | > +-------------------------------------------+ > > So we have 3 distinct states. > > Note: > - 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? 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. -- Eduardo