From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpYaY-0001Br-88 for qemu-devel@nongnu.org; Thu, 29 Sep 2016 06:29:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpYaX-0005am-Bo for qemu-devel@nongnu.org; Thu, 29 Sep 2016 06:29:14 -0400 Date: Thu, 29 Sep 2016 12:29:04 +0200 From: Kashyap Chamarthy Message-ID: <20160929102904.v7xphrkrv2sxqwj3@eukaryote> References: <20160929083435.GE5312@redhat.com> <20160929084325.GA1118@lemon> <20160929085109.GG5312@redhat.com> <20160929090920.GB1118@lemon> <20160929091752.GB5742@noname.redhat.com> <20160929094337.GJ5312@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160929094337.GJ5312@redhat.com> Subject: Re: [Qemu-devel] RFC: handling image options with drive-mirror/drive-backup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , qemu-block@nongnu.org, Fam Zheng , qemu-devel@nongnu.org, Stefan Hajnoczi On Thu, Sep 29, 2016 at 10:43:37AM +0100, Daniel P. Berrange wrote: > On Thu, Sep 29, 2016 at 11:17:52AM +0200, Kevin Wolf wrote: [...] > > Just to clarify what "not stable" means: Literally none of the > > blockdev-add commands that used to work when it was originally merged > > are still working. And we're considering another similar change > > (removing the "options" indirection) that will change the command for > > all users. So while I would encourage libvirt to write prototyp code for > > supporting blockdev-add now, I would advise against enabling it in a > > release yet. > > Urgh, arbitrarily changing behaviour of existing commands is really > very bad for libvirt, as it means we have to now write special case > logic to detect whether we can use the command or not, instead of > merely detecting whether it exists. > > If commands are expected to change, they should have an 'x-' prefix > and once that's removed they should never be changed in an incompatible > manner again. I too wondered about the "x-" prefix for 'blockdev-add' when I was digging into the details a month ago. I came to the conclusion that it was just an inadvertant mistake that it wasn't marked as such -- because, you could see the experimental prefix for rest of them commands: x-blockdev-change x-blockdev-del, x-blockdev-insert-medium, x-blockdev-remove-medium -- /kashyap