From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VotAf-0000uJ-MJ for qemu-devel@nongnu.org; Fri, 06 Dec 2013 06:02:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VotAY-0001GH-0o for qemu-devel@nongnu.org; Fri, 06 Dec 2013 06:02:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VotAX-0001Fp-NK for qemu-devel@nongnu.org; Fri, 06 Dec 2013 06:02:01 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB6B21au021333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Dec 2013 06:02:01 -0500 Message-ID: <52A1AED3.2030203@redhat.com> Date: Fri, 06 Dec 2013 12:02:43 +0100 From: Max Reitz MIME-Version: 1.0 References: <52A0BAD8.90001@redhat.com> <52A0C77F.8060200@redhat.com> <20131206104510.GB2911@dhcp-200-207.str.redhat.com> In-Reply-To: <20131206104510.GB2911@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] Using BlockdevRef in the block layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: "qemu-devel@nongnu.org" , Stefan Hajnoczi On 06.12.2013 11:45, Kevin Wolf wrote: > Am 05.12.2013 um 19:35 hat Max Reitz geschrieben: >> On 05.12.2013 18:41, Max Reitz wrote: >>> [=E2=80=A6] >>> >>> Second, if specifying a reference to an existing device should >>> really be supported, bdrv_open() should ideally not call >>> bdrv_file_open() anymore, but a function bdrv_find_ref() instead >>> which resolves a BlockdevRef structure (for simplicity, it appears >>> to be easier to use a QDict equivalent to a BlockdevRef instead of >>> the latter itself (since that results in many effectively >>> redundant conversions to and from those representations)). >>> However, bdrv_file_open() supports parsing protocol filenames, >>> which bdrv_find_ref() would not. As a result, it is probably best >>> to call bdrv_find_ref() from bdrv_file_open() instead and leave >>> bdrv_open() generally the way it is right now =E2=80=93 yes, this is = a >>> question. ;-) (=E2=80=9CDo you agree?=E2=80=9D) >> I noticed only just now that the current design does not seem to >> allow nesting of files (i.e., driver=3Dblkdebug-qmp, >> file.driver=3Dqcow2, file.file.driver=3Dfile). Perhaps I do have to ca= ll >> bdrv_find_ref() in bdrv_open() and only resort to bdrv_file_open() >> if a filename that must be parsed was given...? > This is supposed to work. If it doesn't work today, it is a bug or > missing implementation rather than a design decision. The top level bdrv_open() will call bdrv_file_open() with {driver=3Dqcow2= ,=20 file.driver=3Dfile}. This in turn calls bdrv_open_common() with file=3DNU= LL=20 which will fail, since qcow2 expects a file to be present=20 (drv->bdrv_file_open =3D=3D NULL && file =3D=3D NULL). At least, that is = what=20 happened for me when I tried this. Max