[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/1] block: Allow passing BlockdevOptions to blo
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH 1/1] block: Allow passing BlockdevOptions to blockdev-snapshot-sync |
Date: |
Wed, 02 Sep 2015 09:04:49 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Kevin Wolf <address@hidden> writes:
> Am 01.09.2015 um 16:22 hat Alberto Garcia geschrieben:
[...]
>> Would you then prefer me to create a new command instead of extending
>> the existing one? What would be the benefit (other than a better name)?
>
> A clean interface. There is really little overlap with what we have:
>
> { 'struct': 'BlockdevSnapshot',
> 'data': { '*device': 'str', '*node-name': 'str',
> 'snapshot-file': 'str', '*snapshot-node-name': 'str',
> '*format': 'str', '*mode': 'NewImageMode' } }
>
> When you add an existing node which has been created with blockdev-add
> as a snapshot, you won't use snapshot-file, snapshot-node-name, format
> and mode. We would either have to make all of them optional and actually
> forbid them when a reference is given, or to ensure that they are
> consistent with the already existing node. That we have both device and
> node-name (and both marked as optional, while one of them is required) is
> also not in line with our current practise.
>
> If we went further that way, the schema wouldn't really be expressive
> any more because there would be too many hidden rules of which
> combinations are allowed and which aren't.
Yes, and let me elaborate a bit.
QMP permits evolving stuff compatibly. We use this capability to keep
things simple and short when we add functionality: we extend existing
stuff instead of duplicating and modifying it. Say, add detail to a
query result, or add an optional command parameter that modifies
behavior.
The question to ask is whether the single, extended interface is still
simpler than a new interface plus the unchanged old one.
I expect introspection to influence our understanding of "simple
interface" going forward. Stuff visible in introspection is usually
simple. Rules of use introspection can't show are often problematic.
[...]