qemu-devel
[Top][All Lists]
Advanced

[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.

[...]



reply via email to

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