[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v3 47/50] paaudio: channel-map option

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v3 47/50] paaudio: channel-map option
Date: Wed, 23 Jan 2019 14:33:48 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 1/23/19 2:13 PM, Zoltán Kővágó wrote:

>>>  { 'struct': 'AudiodevPaPerDirectionOptions',
>>>    'data': {
>>> -    '*name': 'str' } }
>>> +    '*name':        'str',
>>> +    '*channel-map': 'str' } }
>> Ah, I see.  Thats why patch #1 creates a AudiodevPaPerDirectionOptions
>> struct with just one field ...
> Yes, I was bitten by it too during a refactor, probably I should write a
> few words about it in the commit message.

Yes, a good commit message tries to anticipate the questions the
reviewer will ask. The "what" is easy to see (read the patch), but the
"why" is the one that determines whether the patch is worth including.

> However, this is the exact reason I'd recommend nested structs instead
> of randomly flattening it when we can.  This way, if we later have to
> add an extra option, we don't end up in a problematic situation, since
> we can't easily change things like 'dev-in' to a structure without
> breaking backward compatibility.

We can support QAPI Alternates, accepting either a string or a struct
for a given member name like 'dev-in'. Admittedly, it's a bit harder to
write C code interfacing with a QAPI alternate type, but at least it is
possible and allows for back-compatibility.  Then again, getting the
struct right in the first place is even nicer than having to make
back-compat tweaks.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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