[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC 19/19] qapi: New QMP command query-schema fo
Re: [Qemu-devel] [PATCH RFC 19/19] qapi: New QMP command query-schema for QMP schema introspection
Mon, 04 May 2015 09:17:57 +0200
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Eric Blake <address@hidden> writes:
> On 04/02/2015 11:29 AM, Markus Armbruster wrote:
>> * Implicit type definitions are made explicit, and given
>> auto-generated names. These names start with ':' so they don't
>> clash with the user's names.
>> Example: a simple union implicitly defines an enumeration type for
>> its discriminator.
> Given that I just tripped over a bug in my series where I failed to
> consider that '*name' and 'name' should be considered the same, I'm
> wondering if we should first update the parse engine to flatten
> shorthand into a canonical form (that is, get to a point where we have a
> list of all names and their C counterparts), rather than having to tweak
> lots of places in the backends to repeatedly make the same translations
> over and over again (stripping off leading '*', converting qapi
> 'default' into C 'q_default', converting qapi 'a-b' into C 'a_b', etc.).
> I bet some of the backend generator gets simpler if the front end reuses
> your work to get into a canonical form on initial parse.
>> The schema generation proper is pretty trivial. Much of the
>> qapi-introspect.py's code actually does something else: convert the
>> output of parse_schema() into a more usable data structure, lowering
>> away uninteresting stuff. This should really be done in qapi.py, so
>> the other generators can use it, too.
However, we can't simply rebase your series onto mine, because mine is
already based on yours. I really, really want to base on your tests,
simplifications and bug fixes.
Rearranging everything now doesn't sound appealing to me.
Let's get our combined work in, except for this PATCH 19, which isn't
>> +++ b/scripts/qapi-introspect.py
>> @@ -0,0 +1,430 @@
>> +def make_implicit_enum_type(name, role, values):
>> + name = ':enum-%s-%s' % (name, role)
> Evidence of my python newbie-ness:
> Here, you are using string formatting (as in 'pattern' % arguments), in
> other patches, I've seen you use concatenation (would look like ':enum-'
> + name + '-' + role). Is there any rhyme or reason why one form should
> be considered over the other?
I'm no Pythonista, either. I use whatever feels more readable.