From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoBdq-0000nl-7X for qemu-devel@nongnu.org; Mon, 19 Oct 2015 10:42:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoBdo-0002Ud-SJ for qemu-devel@nongnu.org; Mon, 19 Oct 2015 10:42:25 -0400 Date: Mon, 19 Oct 2015 16:42:16 +0200 From: Kevin Wolf Message-ID: <20151019144216.GF5408@noname.redhat.com> References: <1444680042-13207-1-git-send-email-mreitz@redhat.com> <1444680042-13207-19-git-send-email-mreitz@redhat.com> <20151019141831.GE5408@noname.redhat.com> <5624FEE3.9040306@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <5624FEE3.9040306@redhat.com> Subject: Re: [Qemu-devel] [PATCH v6 18/39] block: Add BlockBackendRootState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Alberto Garcia , qemu-block@nongnu.org, John Snow , qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 19.10.2015 um 16:32 hat Max Reitz geschrieben: > 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? >=20 > 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. Sorry, I meant "no blockdev-add way", i.e. hotplug an empty BB in QMP. > > 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. >=20 > I really wouldn't want to use the BBRS for anything but legacy support > (i.e. change inheriting the options of the last medium)... Fair enough. Then I guess it was a random stupid thought. > > Another related question is whether we want to separate out BB options > > (which would otherwise be shared between the BBRS and BDS variants) into > > their own dict. This dict could be optional and that would be the way to > > 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 not > > 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? >=20 > Not on the latter part. Pity. Kevin --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWJQFIAAoJEH8JsnLIjy/WN9AQAJtTBH4T9Nud6qhBPb9txhJ6 /u6HH8QVyDEMvERkoQlYIofWJ6nWuow4jsccRDUNYUxJ38prVIgwwQIqhluUQOl2 ZKIRJafvpV9xh86Sb4cKudq1mt7OSdM+ao5d8X3xgR+kD/w2wX+CT+BW/fUPmzBj PUyXgMfery8a7I4yIShN/N8+za6Vqh41OdtjaCihxrfTgCUZ6UK8l6CKZWw7D2tL GdkDvOJXOAy5wmk2+No8awofr//RvmcZ68sgpZDw29rzncbigu5Lib2KD8Pq40dZ lT+7P/wQ37d/JI8Yxgn6g5UfiewCmTo+4nBD3zk31P1eR6tf2DWOnKudKOP+ZvAY 6sxA3cHjwXmJZO+L8txUgO/0580ssWuVwrnU9KhKtl2fHVJmIxjYYngNHkzy6O8i sOjS1TP0B9kmrwT740s/ReowHveRKsW005mCR2c/24Jyhhzs9WDjZmkIgNYp6hJQ y1rMwO8guB7xmD+B+VSeZ16LP8eAiGN1a2QeaplDFA6+P+1yS1xys2MLGXrrfJ8I HYXhQz32HwRznstgUsACQEOfnhlz59luYKGiXc9FZY0AI6TkTzENaZf3ROWPHblG wm05n5csu++iw3l0J1IIiZpOtR9sXiLsvluwpMDFWWK55OHwBY6C6/opvElTOaz+ 41JUttxuxl8QOrkCVJsc =PTrR -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--