qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 2/3] block: add block-backup QMP command


From: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH v2 2/3] block: add block-backup QMP command
Date: Mon, 13 May 2013 09:18:58 -0400

On Mon, 13 May 2013 15:09:31 +0200
Kevin Wolf <address@hidden> wrote:

> Am 13.05.2013 um 14:56 hat Eric Blake geschrieben:
> > On 05/13/2013 02:28 AM, Kevin Wolf wrote:
> > 
> > >>> +{ 'command': 'block-backup',
> > >>> +  'data': { 'device': 'str', 'target': 'str', '*format': 'str',
> > >>
> > >> Hmm - wondering if we should add an enum type for supported disk formats
> > >> instead of using free-form strings.  The wire representation would be
> > >> the same, and now's the time to do it before we add introspection (it's
> > >> more than just this command impacted).
> > > 
> > > And ideally we shouldn't make it a static list that contains every
> > > format for which qemu has some code, but only those that are actually
> > > compiled in. (Hm, and probably not protocols?)
> > > 
> > > Luiz, any idea how to do something like this, a QAPI enum with values
> > > that are determined at runtime? Especially with respect to the coming
> > > schema introspection?
> > 
> > Or maybe we make the 'enum' list ALL possible types, but then add a
> > query-* command that returns an array of only those enum values that are
> > supported.  Introspection would see all types, but the query command
> > would be the useful variant that is runtime-dependent.

Agreed. This is a capability, and we're adding query- commands to query
capabilities.

> Then is there any advantage in making it an enum in the first place?

Eric is in a better position to answer this, but the fact that this can
be queried isn't a strong pro for having it?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]