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

[Kevin Wolf]

Am 13.05.2013 um 16:14 hat Eric Blake geschrieben:
> On 05/13/2013 07:18 AM, Luiz Capitulino wrote:
> >>>> 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?
> 
> Hmm, you raise an interesting point - if we have a query-block-formats
> command that returns an array of strings, then keep 'str' everywhere
> else a format is required, that is no different for what is sent over
> the wire compared to a query-block-formats that returns an array of
> 'BlockFormat' enum values, with the enum showing all possible formats
> (even if support wasn't compiled in), and with 'BlockFormat' everywhere
> else.  Introspection-wise, you'd have to know that you call
> query-block-formats instead of introspecting on the type of the format
> argument, but information-wise, there's no loss of details if the query-
> command provides the runtime list, and the remaining commands stick with
> 'str'.  I still think an enum is a bit nicer from the type-safety
> aspect, but I'm finding it hard to envision any scenario where libvirt
> would have to resort to introspection if we have a query-block-formats
> in place, and thus am not opposed to your idea of avoiding the enum.

I think long term we'll need a dynamic schema anyway. As we go forward
with modularisation and putting things into shared libraries, we'll have
modules that add support for commands, enum values, etc.

Providing the full list of theoretically available elements (i.e. what
would be there, if everything was compiled and all modules were loaded)
would probably implement the spec for the introspection interfaces by the
letter, but just give useless information. Callers want to know what's
really there.

If we're going to have a query-* command for everything, then we don't
need introspection at all. I would however prefer having the uniform
schema introspection and building the schema at runtime instead of many
separate query-* commands.

Kevin