On Fri, Jul 14, 2017 at 05:32:10PM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Fri, Jul 14, 2017 at 01:04:23PM +0800, Peter Xu wrote:
> > > On Wed, Jul 12, 2017 at 04:05:58PM -0300, Eduardo Habkost wrote:
> > > > On Wed, Jul 12, 2017 at 02:53:40PM +0800, Peter Xu wrote:
> > > > [...]
> > > > > These properties should only be used for debugging/testing purpose,
> > > > > and we should not guarantee any interface compatibility for them (just
> > > > > like HMP).
> > > >
> > > > If we don't guarantee compatibility, the property names need to
> > > > be prefixed with "x-".
> > >
> > > Indeed. Sorry I missed that.
> > >
> > > But I'd say it is slightly awkward to add "x-" for all these (for me,
> > > "x-" means more like "this is not stable and experimental, use it
> > > carefully", while this does not suite for this series). Maybe I can
> > > just remove this sentence in commit log (I think I am just a little
> > > bit frightened by the compatibility problems)...
> >
> > "x-" in property names doesn't mean "experimental", but just "not
> > part of the stable interface". If you have the tiniest doubt
> > about command-line compatibility, I think it won't hurt to use
> > "x-".
>
> We have:
> DEFINE_PROP_MIG_CAP("xbzrle", MIGRATION_CAPABILITY_XBZRLE),
>
> so we could easily do:
> DEFINE_PROP_MIG_CAP("x-xbzrle", MIGRATION_CAPABILITY_XBZRLE),
>
> to ensure that all of the things we expose as props here have
> that added fealing of uncertainty but don't change what migration
> parameters see.
I was thinking to ask either you or Juan on what you would like for
this, looks like I got the answer now. :-) Let me add "x-" to them.
>
>
> (It's a shame we have to have those lists manually, there are so
> many manual places for each parameter and capability)
Temporarily I think it's still okay. But indeed you are right.
--
Peter Xu
