Re: [Qemu-devel] How to introduce bs->node_name ?

[Eric Blake]

On 11/01/2013 08:51 AM, Luiz Capitulino wrote:
> On Wed, 30 Oct 2013 13:25:35 -0600
> Eric Blake <address@hidden> wrote:
> 
>> On 10/30/2013 07:49 AM, Markus Armbruster wrote:
>>
>>>
>>> The first proposal is to add another parameter, say "id".  Users can
>>> then refer either to an arbitrary BDS by "id", or (for backward
>>> compatibility) to the root BDS by "device".  When the code sees
>>> "device", it'll look up the BB, then fetch its root BDS.
>>>
>>> CON: Existing parameter "device" becomes compatibility cruft.
>>>
>>> PRO: Clean and obvious semantics (in my opinion).
>>
>> I like this one as well.
> 
> Does this proposal makes "device" optional for existing commands? If it
> does then I'm afraid it breaks compatibility because if you don't
> specify a device you'll get an error today.

Changing from error to success is not backwards-incompatible.  Old
applications will ALWAYS supply device (because it used to be
mandatory).  That is, a management application that was intentionally
omitting 'device' and expecting an error is so unlikely to exist that we
can consider such a management app as buggy.

For more examples of conversion from error to success, consider the
'block-commit' command.  As introduced in 1.3, we did not yet have the
implementation to commit the current image.  But we designed the command
with a view to the future (which we are nearly at, by the way, although
I don't know if it will make 1.7 or be delayed to 1.8).  In fact, we
specifically made the 'top' argument mandatory at the time, and
documented that if 'top' was the active layer that the command would
fail; but with the full intent of removing the error and instead
succeeding once we implement full commit; we also discussed the
possibility in the 1.3 time-frame that 'top' could be made optional once
block-commit could manage the current image.

> 
> Have you considered adding new commands instead?

I'm still not convinced we need new commands yet.  But again, proposing
the QMP schema first will make that clearer.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature