[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 4/4] qapi: introduce CONFIG_READ event
|
From: |
Markus Armbruster |
|
Subject: |
Re: [PATCH 4/4] qapi: introduce CONFIG_READ event |
|
Date: |
Wed, 18 Oct 2023 14:02:08 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Daniel P. Berrangé <berrange@redhat.com> writes:
> On Wed, Oct 18, 2023 at 06:51:41AM -0400, Michael S. Tsirkin wrote:
>> On Wed, Oct 18, 2023 at 12:36:10PM +0200, Markus Armbruster wrote:
>> > > x- seems safer for management tool that doesn't know about "unstable"
>> > > properties..
>> >
>> > Easy, traditional, and unreliable :)
>>
>> > > But on the other hand, changing from x- to no-prefix is already
>> > > done when the feature is stable, and thouse who use it already
>> > > use the latest version of interface, so, removing the prefix is
>> > > just extra work.
>> >
>> > Exactly.
>> >
>>
>> I think "x-" is still better for command line use of properties - we
>> don't have an API to mark things unstable there, do we?
>
> Personally I like to see "x-" prefix present *everywhere* there is
> an unstable feature, and consider the need to rename when declaring
> it stable to be good thing as it sets an easily identifiable line
> in the sand and is self-evident to outside observers.
>
> The self-documenting nature of the "x-" prefer is what makes it most
> compelling to me. A patch submission, or command line invokation or
> an example QMP command, or a bug report, that exhibit an 'x-' prefix
> are an immediate red flag to anyone who sees them.
Except when it isn't, like in "x-origin".
> If someone sees a QMP comamnd / a typical giant QEMU command line,
> they are never going to go look at the QAPI schema to check whether
> any feature used had an 'unstable' marker. The 'unstable' marker
> might as well not exist in most cases.
>
> IOW, having the 'unstable' flag in the QAPI schema is great for machine
> introspection, but it isn't a substitute for having an 'x-' prefix used
> for the benefit of humans IMHO.
I'm not sure there's disagreement. Quoting myself:
The "x-" can remind humans "this is unstable" better than a feature
flag can (for machines, it's the other way round).
CLI and HMP are for humans. We continue to use "x-" there.
QMP is for machines. The feature flag is the sole source of truth.
Additional use of "x-" is fine, but not required.
- [PATCH 3/4] qapi: device-sync-config: check runstate, (continued)
- [PATCH 3/4] qapi: device-sync-config: check runstate, Vladimir Sementsov-Ogievskiy, 2023/10/06
- [PATCH 1/4] vhost-user-blk: simplify and fix vhost_user_blk_handle_config_change, Vladimir Sementsov-Ogievskiy, 2023/10/06
- [PATCH 4/4] qapi: introduce CONFIG_READ event, Vladimir Sementsov-Ogievskiy, 2023/10/06
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Markus Armbruster, 2023/10/17
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Vladimir Sementsov-Ogievskiy, 2023/10/17
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Markus Armbruster, 2023/10/18
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Vladimir Sementsov-Ogievskiy, 2023/10/18
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Markus Armbruster, 2023/10/18
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Michael S. Tsirkin, 2023/10/18
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Daniel P . Berrangé, 2023/10/18
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event,
Markus Armbruster <=
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Daniel P . Berrangé, 2023/10/18
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Dr. David Alan Gilbert, 2023/10/18
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Markus Armbruster, 2023/10/19
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Markus Armbruster, 2023/10/19
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Vladimir Sementsov-Ogievskiy, 2023/10/18
- Re: [PATCH 4/4] qapi: introduce CONFIG_READ event, Markus Armbruster, 2023/10/19
[PATCH 2/4] qapi: introduce device-sync-config, Vladimir Sementsov-Ogievskiy, 2023/10/06