From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:60170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ggs6U-0006cl-9p for qemu-devel@nongnu.org; Tue, 08 Jan 2019 09:11:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ggs6T-0003fH-DE for qemu-devel@nongnu.org; Tue, 08 Jan 2019 09:11:38 -0500 From: Paul Durrant Date: Tue, 8 Jan 2019 14:11:05 +0000 Message-ID: References: <20181220171439.11159-1-paul.durrant@citrix.com> <20181220171439.11159-17-paul.durrant@citrix.com> <20190104163124.GE1508@perard.uk.xensource.com> <20190108125321.GD11492@linux.fritz.box> <904d305f8c0f4aac8e60fb7ea14ebd41@AMSPEX02CL03.citrite.net> <20190108132823.GF1508@perard.uk.xensource.com> In-Reply-To: <20190108132823.GF1508@perard.uk.xensource.com> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v7 16/18] xen: automatically create XenBlockDevice-s List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Perard Cc: 'Kevin Wolf' , "qemu-devel@nongnu.org" , "qemu-block@nongnu.org" , "xen-devel@lists.xenproject.org" , Max Reitz , Stefano Stabellini > -----Original Message----- > From: Anthony PERARD [mailto:anthony.perard@citrix.com] > Sent: 08 January 2019 13:28 > To: Paul Durrant > Cc: 'Kevin Wolf' ; qemu-devel@nongnu.org; qemu- > block@nongnu.org; xen-devel@lists.xenproject.org; Max Reitz > ; Stefano Stabellini > Subject: Re: [PATCH v7 16/18] xen: automatically create XenBlockDevice-s >=20 > On Tue, Jan 08, 2019 at 01:07:49PM +0000, Paul Durrant wrote: > > > -----Original Message----- > > > From: Kevin Wolf [mailto:kwolf@redhat.com] > > > Sent: 08 January 2019 12:53 > > > To: Paul Durrant > > > Cc: Anthony Perard ; qemu-devel@nongnu.org= ; > > > qemu-block@nongnu.org; xen-devel@lists.xenproject.org; Max Reitz > > > ; Stefano Stabellini > > > Subject: Re: [PATCH v7 16/18] xen: automatically create > XenBlockDevice-s > > > > > > Am 04.01.2019 um 17:40 hat Paul Durrant geschrieben: > > > > > -----Original Message----- > > > > > From: Anthony PERARD [mailto:anthony.perard@citrix.com] > > > > > Sent: 04 January 2019 16:31 > > > > > To: Paul Durrant > > > > > Cc: qemu-devel@nongnu.org; qemu-block@nongnu.org; xen- > > > > > devel@lists.xenproject.org; Kevin Wolf ; Max > Reitz > > > > > ; Stefano Stabellini > > > > > Subject: Re: [PATCH v7 16/18] xen: automatically create > > > XenBlockDevice-s > > > > > > > > > > Almost done, there is one thing left which I believe is an issue. > > > > > Whenever I attach a raw file to QEMU, it print: > > > > > qemu-system-i386: warning: Opening a block device as a file > using > > > the > > > > > 'file' driver is deprecated > > > > > > > > Oh, I'd not noticed that... but then I only use raw files > occasionally. > > > > > > Strictly speaking, this is not about raw (regular) files, but raw > block > > > devices. 'file' is fine for actual regular files, but the protocol > > > driver for block devices is 'host_device'. > > > > > > > > raw files should use the "raw" driver, so we aren't done yet. > > > > > > > > Ok. Having a strictly 2-layer stack actually makes things simpler > anyway > > > :-) > > > > > > Using 'raw' there will make the block layer auto-detect the right > > > protocol layer, so this works. If you want to avoid the second layer, > > > you'd have to figure out manually whether to use 'file' or > > > 'host_device'. > > > > Thanks for the explanation. I'll give it a spin using a device... I've > posted v8 but, given what you say, I'm still not sure I have it right. >=20 > Indeed, in v8, even with the extra 'raw' layer, the warning is still > there. I was trying to understand why, and I only found out today that > we would need to use the 'host_device' driver as explain by Kevin. >=20 >=20 > BTW Paul, we can simplify the code that manage layers, by not managing > them. > Instead of (in JSON / QMP term): > { 'driver': 'file', 'filename': '/file', 'node-name': 'node-file' } > { 'driver': 'qcow2', 'file': 'node-file', 'node-name': 'node-qcow2' } > we can have: > { 'driver': 'qcow2', 'node-name': 'node-qcow2', > 'file': { 'driver': 'file', 'filename': '/file' } } > I kind of like the clean separation though... From what Kevin said, it soun= ds like the lowest layer should use 'raw' instead of 'file' to DTRT, and th= en we should be back to only needing the single layer in that case. I'll re= vert back to v7 and give it a try. Paul