qemu-devel
[Top][All Lists]
Advanced

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

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 0/1] Get the list of arguments from a QMP command
Date: Wed, 11 Mar 2015 20:22:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Alberto Garcia <address@hidden> writes:

> On Wed, Mar 11, 2015 at 11:21:43AM +0100, Markus Armbruster wrote:
>
>> > I can actually try to implement full introspection support, but I
>> > would like to know what API you would like. Something like this?
>> >
>> >    'query-commands'
>> >    'query-enums'
>> >    'query-events'
>> >    'query-types'
>> >    'query-unions'
>> 
>> You propose a separate query-FOO for each kind of thing in the
>> schema: command, event, the various types.  Not fundamentally
>> different to a single query-schema.  We can discuss which of the two
>> approaches is easier to use.
>
> I don't think it makes much difference in terms of complexity
> from the QEMU side. I proposed those because query-commands and
> query-events already exist, so adding the missing ones seemed the most
> straightforward solution to me.

They only tell you what commands and events exist, but nothing about
their 'data' or 'returns'.

> But if query-schema is more convenient I don't have any problem with
> that.

The real work is processing the full schema into the externally visible
sub-schema.  Whether to split it into several parts for presentation is
the least of my worries.

I'm fine with with building up introspection step by step.  But I want
us to have a reasonable idea of the end result.  Without that,
incremental development together with our ABI promise is prone to
produce a tangled mess.  We already have enough of those :)

I feel a necessary early step is to actually define our schema language,
and separate syntactic sugar from its core.  Introspection wants the
core, but for schema development, a modest amount of sugar is
convenient.  Some of the current schema syntax needs to be redefined as
sugar for a suitable desugared form.  We've discussed this for "asterisk
means optional" already.  Eric's series brings us closer, it just needs
to be finished.

If we can't crack the whole problem in the next development cycle,
perhaps we can identify a minimally useful sub-schema that is unlikely
to be affected by the above work.  We could then expose that early, with
the idea of extending it later.

[...]



reply via email to

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