[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/3] migration: export cap/params to qdev props
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH 0/3] migration: export cap/params to qdev props |
Date: |
Fri, 14 Jul 2017 17:32:10 +0100 |
User-agent: |
Mutt/1.8.3 (2017-05-23) |
* Eduardo Habkost (address@hidden) 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.
(It's a shame we have to have those lists manually, there are so
many manual places for each parameter and capability)
Dave
>
> --
> Eduardo
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- [Qemu-devel] [PATCH 2/3] migration: export parameters to props, (continued)