[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState |
Date: |
Tue, 30 Oct 2018 20:15:45 -0300 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
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é <address@hidden> 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
- [Qemu-devel] [PATCH 0/4] Introducing QemuSupportState, Gerd Hoffmann, 2018/10/30
- [Qemu-devel] [PATCH 2/4] add QemuSupportState to DeviceClass, Gerd Hoffmann, 2018/10/30
- [Qemu-devel] [PATCH 4/4] switch machine types to QemuSupportState, Gerd Hoffmann, 2018/10/30
- [Qemu-devel] [PATCH 1/4] add QemuSupportState, Gerd Hoffmann, 2018/10/30
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, Philippe Mathieu-Daudé, 2018/10/30
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, Gerd Hoffmann, 2018/10/30
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, Philippe Mathieu-Daudé, 2018/10/30
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, Cornelia Huck, 2018/10/30
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, Philippe Mathieu-Daudé, 2018/10/30
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState,
Eduardo Habkost <=
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, Cornelia Huck, 2018/10/31
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, John Snow, 2018/10/31
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, Eduardo Habkost, 2018/10/31
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, John Snow, 2018/10/31
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, Eduardo Habkost, 2018/10/31
- Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, John Snow, 2018/10/31
Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, Eduardo Habkost, 2018/10/30
Re: [Qemu-devel] [PATCH 1/4] add QemuSupportState, Eduardo Habkost, 2018/10/30
Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/4] add QemuSupportState, Murilo Opsfelder Araujo, 2018/10/30
[Qemu-devel] [PATCH 3/4] tag cirrus as obsolete, Gerd Hoffmann, 2018/10/30