From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46446) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpcZ6-0006nR-Oy for qemu-devel@nongnu.org; Fri, 23 Oct 2015 09:39:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZpcZ0-0002IP-FR for qemu-devel@nongnu.org; Fri, 23 Oct 2015 09:39:28 -0400 Date: Fri, 23 Oct 2015 15:39:12 +0200 From: Kevin Wolf Message-ID: <20151023133912.GD3797@noname.redhat.com> References: <1445270025-22999-1-git-send-email-mreitz@redhat.com> <1445270025-22999-32-git-send-email-mreitz@redhat.com> <5627978B.3090403@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <5627978B.3090403@redhat.com> Subject: Re: [Qemu-devel] [PATCH v7 31/39] blockdev: Add blockdev-insert-medium 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 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 21.10.2015 um 15:47 hat Max Reitz geschrieben: > On 21.10.2015 13:49, Alberto Garcia wrote: > > On Mon 19 Oct 2015 05:53:37 PM CEST, Max Reitz wrote: > >> And a helper function for that, which directly takes a pointer to the > >> BDS to be inserted instead of its node-name (which will be used for > >> implementing 'change' using blockdev-insert-medium). > >=20 > > Shouldn't this update bdrv_states? >=20 > I hate bdrv_states. >=20 > Yes, it should. Thanks! Once your reimplement blk_set_bs() on top of blk_insert/remove_bs(), this logic would replace the code in change_parent_backing_link(). Of course, I left the list update in block.c for a reason, it's meant to be an internal data structure, so your code accessing it from outside won't be much nicer. Do we actually still need bdrv_states or can we get rid of it in a follow-up series? If so, I wouldn't mind an ugly intermediate state. Kevin --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWKjiAAAoJEH8JsnLIjy/WRZwQALBrnvGmPReA34kqg+oL2fAW INaPfrPPL99Z79YHrb7bZ8OEm/+CW3hZUzpF5ZVyyqFw5rqhq/uVzzd/kq0GpzgL 4VCRALltHV6HFYAKIHD0936lTBJd/nPcOiS8PDE5wD9jl05wIuYjbrxmCHJOEyIM UTQOtzXXPAALfnnreC72r6aqxB3ZvQOVYMBwxSza2bH0HU8hf9D0WPidg0BMWtwP rXVYmGRO3OrMr9TI5z/Vuqh6ACKhsFbTHGyo8ezOCN+PaIj9ZISLVHaOqrp56ded hvRpAIH2ASgYsPcSXWoYT8pXB9PwzcLZAeZwg/tiqCdS9J4hUkd8I6gRk+eF698l lKloaGSnwhjJQg24PhmuUG+w4x7+n324Lfxh2HqeXmKRGUOU7Dfnbb4dVkGKl6Gu eWnRb9u2zaCY0fkLnh+XVOx8IPpxwcz2KaJoqFFUNm9wZL9WhaMA+uusPR/wYzCq DOMkTbYRoqmPSp6kfrUyWV6Oe3MXatkIM1rcbEg4ZX9x+q8oNqtSEwNnOb1Z6xbz GJKDtTX2WOxCV+8UjSXiewZKIWd4o42UCmxXTz3zrmOR3OvEIaLbBXjtixr4YqI2 NcDch1rb23529myypPHRmScMvgBGVYpyZ3xsECqRGQZVrjC6DDRNOFUluElreuhI w7Y2waxvJA+bdtitzX3w =mkxK -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q--