From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:59440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gqbIr-00039G-Uc for qemu-devel@nongnu.org; Mon, 04 Feb 2019 05:16:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gqbIm-0003hm-0x for qemu-devel@nongnu.org; Mon, 04 Feb 2019 05:16:33 -0500 Date: Mon, 4 Feb 2019 10:06:27 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Message-ID: <20190204100627.GB1905@redhat.com> Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20190125174653.4604-1-kwolf@redhat.com> <20190125174653.4604-4-kwolf@redhat.com> <20190129155832.GJ30796@redhat.com> <20190204095628.GC5855@linux.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190204095628.GC5855@linux.fritz.box> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 3/3] scsi-disk: Deprecate device_id fallback to BlockBackend name List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-block@nongnu.org, armbru@redhat.com, pbonzini@redhat.com, pkrempa@redhat.com, eblake@redhat.com, libvir-list@redhat.com, qemu-devel@nongnu.org On Mon, Feb 04, 2019 at 10:56:28AM +0100, Kevin Wolf wrote: > Am 29.01.2019 um 16:58 hat Daniel P. Berrang=C3=A9 geschrieben: > > On Fri, Jan 25, 2019 at 06:46:53PM +0100, Kevin Wolf wrote: > > > We should never have exposed BlockBackend names to the guest, it's = a > > > host detail. Deprecate this behaviour. Users who need to maintain t= he > > > guest ABI can explicitly set the value with the device_id property. > >=20 > > I don't think we've deprecated things in the past which would cause > > a guest ABI change when finally deleted. > >=20 > > Shouldn't we be instead setting using machine type versioning here, > > so that existing machine types keep using the blk_name() fallback > > forever, while QEMU 4.0+ machine types avoid blk_name() fallback > > immediately. >=20 > I was going to implement this, but then I wondered if that's actually > worthwhile. With -blockdev, you don't get the bad behaviour anyway, and > tools that would select new machine types will hopefully also use new > backend options. >=20 > So if we need to keep the bad behaviour around anyway instead of > completely removing it as I intended originally, maybe -drive vs. > -blockdev is enough to make the difference and we shouldn't change > anything at the device model level at all. Yeah, that rationale sounds ok to me. Regards, Daniel --=20 |: https://berrange.com -o- https://www.flickr.com/photos/dberran= ge :| |: https://libvirt.org -o- https://fstop138.berrange.c= om :| |: https://entangle-photo.org -o- https://www.instagram.com/dberran= ge :|