From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VcGP3-0006eo-Az for qemu-devel@nongnu.org; Fri, 01 Nov 2013 11:12:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VcGOx-0002nf-BD for qemu-devel@nongnu.org; Fri, 01 Nov 2013 11:12:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VcGOx-0002nU-1z for qemu-devel@nongnu.org; Fri, 01 Nov 2013 11:12:43 -0400 Date: Fri, 1 Nov 2013 11:12:35 -0400 From: Luiz Capitulino Message-ID: <20131101111235.381c8373@redhat.com> In-Reply-To: <5273C1C8.4010601@redhat.com> References: <20131028154038.GG2890@irqsave.net> <87eh72eumr.fsf@blackfin.pond.sub.org> <52715D2F.8000109@redhat.com> <20131101105139.3635bd82@redhat.com> <5273C1C8.4010601@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] How to introduce bs->node_name ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: =?UTF-8?B?QmVub8OudA==?= Canet , kwolf@redhat.com, Markus Armbruster , stefanha@redhat.com, qemu-devel@nongnu.org On Fri, 01 Nov 2013 08:59:20 -0600 Eric Blake wrote: > On 11/01/2013 08:51 AM, Luiz Capitulino wrote: > > On Wed, 30 Oct 2013 13:25:35 -0600 > > Eric Blake 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.