qemu-devel
[Top][All Lists]
Advanced

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

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


From: Luiz Capitulino
Subject: Re: [Qemu-devel] How to introduce bs->node_name ?
Date: Fri, 1 Nov 2013 11:12:35 -0400

On Fri, 01 Nov 2013 08:59:20 -0600
Eric Blake <address@hidden> wrote:

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

Doing such changes makes me nervous nevertheless. In my mind a stable
API doesn't change. Of course that there might exceptions, but 99.9%
of those exceptions should be bug fixes not deliberate API extensions.

A more compelling argument against it is the quality of the resulting
command. I'm sure it's going to be anything but a simple, clean API.

Anyways, let's wait for a concrete proposal to have more concrete
feedback.



reply via email to

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