Re: [Qemu-devel] [PATCH 0/1] Get the list of arguments from a QMP command

[Kevin Wolf]

Am 06.03.2015 um 18:11 hat Eric Blake geschrieben:
> On 02/24/2015 06:51 AM, Alberto Garcia wrote:
> > Hello,
> > 
> > this is a follow-up to the comments from Eric Blake about my patches
> > to extend the block streaming API:
> > 
> >    https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg04231.html
> > 
> > Since QEMU doesn't have an easy way to tell the arguments that a
> > particular QMP command supports, and it seems that it would be useful
> > for libvirt and possibly others, I decided to write a simple patch
> > that adds that feature.
> 
> This is potentially a step in the right direction for full
> introspection, but I'm a bit worried that it's half-baked.  That is, it
> only states whether an argument is present or not, but doesn't say what
> type those arguments are, and most glaringly, doesn't tell me anything
> about type changes, such as adding new enum values or new struct
> members.  In other words, while this interface might help libvirt, it
> won't solve all the qapi questions that libvirt has, and I'm worried
> that committing this and then adding full introspection will burden us
> with multiple implementations to keep running.

I suggested going this route to Alberto because our previous attempts on
doing the full introspection all have failed, and requesting to do such
a large project on the side just for getting in some block layer
improvements wouldn't be fair.

Sometimes it's just more realistic to approach things incrementally.
It's the same thing with the blockdev work: We're still not fully there,
but discussing about the full solution for three more years wouldn't
have helped either.

As far as I can tell, this approach is extensible enough that the other
relevant information can be added later without breaking the API. I
believe this is what we should concentrate on now rather than insisting
that the implementation must be complete from the start.

> > Feedback is welcome.
> 
> I'm still thinking about the actual patch, and whether we want to commit
> to this or just bite the bullet and go for full introspection.  At any
> rate, it's a bit late for 2.3, so we have the full 2.4 cycle to get it
> right.

If someone were to provide full introspection for 2.4, that would be
best. But I'd rather merge something like this than having nothing for
another couple of releases.

Kevin

pgpaWYdjsq2fc.pgp
Description: PGP signature