From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhMZo-0004AX-H9 for qemu-devel@nongnu.org; Thu, 23 Oct 2014 13:53:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhMZj-0002kg-Jg for qemu-devel@nongnu.org; Thu, 23 Oct 2014 13:53:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhMZj-0002ka-BX for qemu-devel@nongnu.org; Thu, 23 Oct 2014 13:53:27 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NHrQZU013301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Oct 2014 13:53:26 -0400 Message-ID: <54494095.70506@redhat.com> Date: Thu, 23 Oct 2014 11:53:25 -0600 From: Eric Blake MIME-Version: 1.0 References: <1414076175-17034-1-git-send-email-mreitz@redhat.com> In-Reply-To: <1414076175-17034-1-git-send-email-mreitz@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iRPvxBiHJrbte43ljvO0pTvaDg2m0UDoh" Subject: Re: [Qemu-devel] [PATCH 0/2] block: JSON filenames and relative backing files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iRPvxBiHJrbte43ljvO0pTvaDg2m0UDoh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/23/2014 08:56 AM, Max Reitz wrote: > Sometimes, qemu does not have a filename to work with (it then generate= s > a JSON filename), so it does not know which directory to use for a > backing file specified by a relative filename. >=20 > In this case, qemu should not somehow try to append the backing file's > name to the JSON object, but rather just print an error and bail out. Hmm. Makes me wonder if we should extend BlockdevOptions to allow for a BDS to additionally track a notion of "current directory" from which any relative names should be interpreted against. That is, something like: TEST_IMG=3D"json:{ 'driver': '$IMGFMT', 'file': { 'driver': 'blkdebug', 'image': { 'driver': 'file', 'filename': '$TEST_IMG' }, + 'rel-dir': '$DIR_OF_TEST_IMG_BACK', 'set-state': [ { 'event': 'read_aio', 'new_state': 42 } ] } }" _img_info | _filter_img_info being a way to let us access the (otherwise relative-only) backing file encoded behind the blkdebug wall with a notion of the correct directory to find it in. Of course, such an extension to BDS description (for both command line and QMP) would be a separate series... --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --iRPvxBiHJrbte43ljvO0pTvaDg2m0UDoh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUSUCVAAoJEKeha0olJ0Nq9lIH/3R10vQa/k1NVpPQm62GGd17 5F5aYAbXwNsBoVrRTNfjH2gWy1UtRWUEvxlrlizwYc6/Y4AE/d5XBKZugXgLXZ1i 5M18l/HGtTUH6dxyBQeS683Mtc6rBFiUmfm5PaPhW52Qk21lfwDK3+3O64fsYCip fYmfmIRv5t8DoAYUAKxFSIuPgTMve1fSXOZuorA5i07tJdO3y+7wuQLlaTnLyRwE nafkjhGXi6V41ByYdxU8FmP6TLPhpUqCxklTCkKrTGAroDIUxcKAAJ7Y2b0lL232 zC5oFb6fN1By3VuAltanOzg1W6E9tl4ZTzXhgCPfAptCV9ejgoTNCETd4gnMuLU= =x/Id -----END PGP SIGNATURE----- --iRPvxBiHJrbte43ljvO0pTvaDg2m0UDoh--