qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/5] qapi flattening + some miscellaneous patche


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 0/5] qapi flattening + some miscellaneous patches
Date: Fri, 03 Jul 2015 11:09:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Gerd Hoffmann <address@hidden> writes:

> On Do, 2015-07-02 at 20:00 +0200, Markus Armbruster wrote:
>> Gerd Hoffmann <address@hidden> writes:
>> 
>> > On Di, 2015-06-23 at 15:32 +0200, Kővágó, Zoltán wrote:
>> >> I've cherry-picked the qapi related parts from my previous -audiodev
>> >> patch series, we can hopefully concentrate on one thing at a time.  The
>> >> most important changes in this patch series are the flattening of the
>> >> Netdev structures.  This way we can add proper nested structure support
>> >> into OptsVisitor, without requiring backward-compatibility hacks.
>> >
>> > Applies and builds fine, no obvious regressions in testing.
>> >
>> > Tested-by: Gerd Hoffmann <address@hidden>
>> >
>> > Getting this merged before hard freeze would be great ...
>> >
>> > Any takers?  Markus?
>> 
>> A first round of review is my best offer, I'm afraid: I'll be away the
>> next two weeks.
>> 
>> Any particular reason why we want this in 2.4?
>
> Looked easy as everybody agreed that flattening the qemu structs is a
> good thing, and merging stuff helps keeping the out-of-tree patch queues
> smaller ...

Fair enough.

The series does three things, I think:

1. QAPI struct flattening [PATCH 2+3]

2. OptsVisitor nesting support [PATCH 1+4]

3. Nicer qemu_opts_print() [PATCH 5]

Regarding 1., I'm fine with the general approach.  In fact, proper
netdev_add qapification will need the flattening anyway (if it's
possible at all, but I'd like to try).  However, PATCH 3 needs a few
comment edits (could be done on commit), and I'd prefer to avoid the
type system cheat.  See my review for details.

Regarding 2., I have questions, and don't think we should rush it.

Regarding 3., I'm again fine with the general idea, but the "quoting for
shell" part doesn't look ready.  Take out that part if you want
something committed *now*.



reply via email to

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