Re: [PATCH 4/4] qapi: introduce CONFIG_READ event

["Dr. David Alan Gilbert" <dave@treblig.org>]

* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Wed, Oct 18, 2023 at 02:02:08PM +0200, Markus Armbruster wrote:
> > 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.
> 
> I guess we have different defintions of "for humans" in this context.
> I consider QMP  data still relevant for humans, because humans are
> reviewing patches to libvirt that add usage of QMP features, or
> triaging bug reports that include examples of usage, and in both
> cases it is pretty relevant to make unstable features stand out to
> the human via the x- prefix IMHO.

Using x- for events makes sense to me; the semantics of events can be
quite subtle; often you don't find out how broken they are until you
wire them through libvirt and up the stack; so it's not impossible
you might need to change it - but then without the x- the semantics
(rather than existence) of the event is carved in stone.

Dave

> With regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/