From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoBTw-0002w0-Il for qemu-devel@nongnu.org; Mon, 19 Oct 2015 10:32:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoBTv-00083s-N4 for qemu-devel@nongnu.org; Mon, 19 Oct 2015 10:32:12 -0400 References: <1444680042-13207-1-git-send-email-mreitz@redhat.com> <1444680042-13207-19-git-send-email-mreitz@redhat.com> <20151019141831.GE5408@noname.redhat.com> From: Max Reitz Message-ID: <5624FEE3.9040306@redhat.com> Date: Mon, 19 Oct 2015 16:32:03 +0200 MIME-Version: 1.0 In-Reply-To: <20151019141831.GE5408@noname.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CllMWftA7sXQiQ1TOep6lwG8BLsIel69M" Subject: Re: [Qemu-devel] [PATCH v6 18/39] block: Add BlockBackendRootState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Alberto Garcia , qemu-block@nongnu.org, John Snow , qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CllMWftA7sXQiQ1TOep6lwG8BLsIel69M Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19.10.2015 16:18, Kevin Wolf wrote: > Am 12.10.2015 um 22:00 hat Max Reitz geschrieben: >> This structure will store some of the state of the root BDS if the BDS= >> tree is removed, so that state can be restored once a new BDS tree is >> inserted. >> >> Signed-off-by: Max Reitz >=20 > Random thought, not directly related to this series: >=20 > We currently don't have a way to create just a BlockBackend with no > medium. If we were to add that, would we want that to be just like a > missing -drive file=3D... option, or would it actually make sense to > specify the BlockBackendRootState? We don't? -drive if=3Dnone,id=3Dfoo works just fine for me. Issuing qemu-= io foo "read 0 512" then prints "read failed: " + strerror(ENOMEDIUM) to stderr. > If we want to do that, we might actually have found a reason why the > 'options' key makes sense in blockdev-add. We could make it a union > where you either describe a BlockBackendRootState or a BDS. I really wouldn't want to use the BBRS for anything but legacy support (i.e. change inheriting the options of the last medium)... > Another related question is whether we want to separate out BB options > (which would otherwise be shared between the BBRS and BDS variants) int= o > their own dict. This dict could be optional and that would be the way t= o > specify whether you want a BB on top or not. Candidates for this dict > are id/rerror/werror. >=20 > There are more fields that exist in both the BDS and BBRS variants, but= > don't really belong to the BB (i.e. they end up in the real BBRS and no= t > in the BB, and are only valid as long as no BDS is attached). These > would not be moved to the BB options dict. >=20 > Any opinions? Not on the latter part. Max --CllMWftA7sXQiQ1TOep6lwG8BLsIel69M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWJP7jAAoJEDuxQgLoOKytPIUIAIAdDhLqRMBXVgtdhkMUt7B9 vWy8Uby8E0ShmO4hH5kvtsrmnCeVmsnz2HJvtPxsFC5w8EYCfwAVo+MSrsIJictk Mwlkl3Xv51MkS/KOEKsoFLwK8rvEMERYljHMzcT2PuvkDtM/rmf7mXO0zYMW14Jt mk9Q9+IBdK0I3v/HZcz4SGUb/PFmRX+fyZl/2vKpbAyg4yXjg275JPEJRgKl2VE8 Tcjjfb3trFvXB+/0F6wn9SIoNFu6bz/w1JTxLvG3O2FuuR9322mbCt6tMAtvM/4M 3uinwyMyP9PO00eD5HTbWAOSLpp9Ih2ZUFgDGdfFIJsjZs2/vlm33VsYR7BF/Qo= =0S9L -----END PGP SIGNATURE----- --CllMWftA7sXQiQ1TOep6lwG8BLsIel69M--