From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHZAc-0001sc-Vs for qemu-devel@nongnu.org; Mon, 27 Jun 2016 12:14:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHZAb-00080z-E6 for qemu-devel@nongnu.org; Mon, 27 Jun 2016 12:13:58 -0400 References: <1466692592-9551-1-git-send-email-kwolf@redhat.com> From: Max Reitz Message-ID: Date: Mon, 27 Jun 2016 18:13:47 +0200 MIME-Version: 1.0 In-Reply-To: <1466692592-9551-1-git-send-email-kwolf@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NJJRQSApbKMHlXA81wPcsGrbD2It0Ar47" Subject: Re: [Qemu-devel] [RFC PATCH 0/7] BlockBackends, nodes and guest devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , qemu-block@nongnu.org Cc: eblake@redhat.com, armbru@redhat.com, stefanha@redhat.com, famz@redhat.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NJJRQSApbKMHlXA81wPcsGrbD2It0Ar47 From: Max Reitz To: Kevin Wolf , qemu-block@nongnu.org Cc: eblake@redhat.com, armbru@redhat.com, stefanha@redhat.com, famz@redhat.com, qemu-devel@nongnu.org Message-ID: Subject: Re: [RFC PATCH 0/7] BlockBackends, nodes and guest devices References: <1466692592-9551-1-git-send-email-kwolf@redhat.com> In-Reply-To: <1466692592-9551-1-git-send-email-kwolf@redhat.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 23.06.2016 16:36, Kevin Wolf wrote: > I am relatively confident to say that everything that should use a > BlockBackend, does so by now. Almost all users create their own anonymo= us > BlockBackend internally and use that. The user configures the BB only > indirectly using the configuration methods of the user that the BB belo= ngs to. >=20 > There is one exception, which are guest devices. There the user is expe= cted to > manually set up a BlockBackend and pass it to the device. This requires= that > users understand the difference between node and BlockBackends and mana= ge both > kinds of objects. This is a rather nasty interface. >=20 > My goal is that we allow a user (management tool) to ignore that BlockB= ackends > exist as separate entities in qemu. Ideally we could fully make them an= > implementation detail, but I'm not sure to which degree we can do that = for > compatibility reasons. But what I'm pretty sure we can do is provide in= terfaces > that address everything using either node names or (qdev) device names,= so that > you don't have to manage BlockBackends if you don't want to. >=20 > This involves several steps, and for most of them this series contains = an > example patch that shows what this could look like: >=20 > 1. Accept node-name in -device drive=3D... and create an internal anony= mous BB > for devices configured this way. This is the way to create devices t= hat > completely avoid legacy interfaces using the BB name. >=20 > 2. Update all QMP commands touching block devices. There are two kinds = of them, > concerning either the guest device (which the BlockBackend is logica= lly part > of, even though it's not implemented this way) or the actual backend= > (BlockDriverState/node level) >=20 > * Device level commands: Accept a guest device ID instead of BB name= to > identify the BlockBackend the command works on. As device IDs and = BB names > don't share a single namespace, we'll need a new QMP argument for = this. >=20 > * Node level commands: We need to complete the conversion that makes= > commands accept node names instead of BlockBackend names. In some = places > we intentionally allow only BlockBackends because we don't know if= the > command works in other places than the root. This is okay, but we = can > accept node names anyway. We just need to check that the node is a= root > node as expected. >=20 > 3. Remove all BlockBackend options from blockdev-add. This has already = happened > partially (e.g. WCE flag), but at least id, rerror, werror are still= there. > This is a very incompatible change, but we declared blockdev-add > experimental, so I think it's acceptable. >=20 > 4. Add BlockBackend options as qdev properties to all block devices. >=20 > 5. Add a way on the command line to create block nodes that have a node= -name > and don't have a BlockBackend. blockdev-add already supports this (a= nd after > implementing 3. it will be the only mode supported by blockdev-add),= but we > can't do this on the command line yet. You always get a BB with -dri= ve. >=20 > This might finally become the -blockdev we were talking about at the= very > beginning of the block layer generalisation work. >=20 > So this is my plan. It's pretty radical, but I think we really must do > something about our interfaces. Having nodes, BlockBackends and guest d= evices > to manage is just too much and doesn't really make sense. Making BlockB= ackends > visible in the external API essentially only as aliases for either node= names > or guest devices (and that only for compatibility, not when using block= dev-add/ > -blockdev) feels to me like the right thing to do. >=20 > But of course I'm aware that there probably isn't a clear right or wron= g, and > that I might be missing important details, so this needs to be discusse= d in > advance before I go and implement the full thing instead of just small = example > patches. >=20 > So please let me know what you guys think about this plan. I agree that the current interface is confusing because of the BB layer that the user (unnecessarily) needs to care about. I don't think we absolutely have to do something about it, but your plan is reasonable and I do consider it an improvement. I'm not sure if WCE truly is a guest device property, but adding it as a guest device property and then syncing it to the BB makes sense (as done in patch 7). Max --NJJRQSApbKMHlXA81wPcsGrbD2It0Ar47 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 iQEvBAEBCAAZBQJXcVC7EhxtcmVpdHpAcmVkaGF0LmNvbQAKCRA7sUIC6DisrZYO B/4p1kgkrEJ4aRDMYsnzr9TFfCIpUcE60zw7bTEnMl+ORpupQW9UdLcNtfYdOD9p SOlARJMn/0V/eunxpTBKSLNrBcy27Y3MuOy7vqufsBlEtSU+IXcuzePkkjMnH6PI q/wClRq1BSZihFsifjjxy62856Cj8rnGyDusSSdiJ5tH1N7UxTmc4ulshpX/fNyL NXsOVWUB8/ty/skJCRNOUEf+FYb+NBzDnWFbGpmLac/uLTicWQ9/gGOf37oIxUGJ zdJy05xjm7kzulW7IZGDA5Vk0XKb6gagUIv/I2ZfZicG4M/PR74GW6s9Fr5TrA8l tqTs7NdYME+LQxA6JL6uCuOZ =1KNp -----END PGP SIGNATURE----- --NJJRQSApbKMHlXA81wPcsGrbD2It0Ar47--