From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49094 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OwHes-0003Bx-Io for qemu-devel@nongnu.org; Thu, 16 Sep 2010 12:50:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OwGZf-00013V-Aj for qemu-devel@nongnu.org; Thu, 16 Sep 2010 11:40:39 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:40515) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OwGZf-00013L-8M for qemu-devel@nongnu.org; Thu, 16 Sep 2010 11:40:35 -0400 Received: by gya1 with SMTP id 1so558963gya.4 for ; Thu, 16 Sep 2010 08:40:34 -0700 (PDT) Message-ID: <4C923A6F.2070604@codemonkey.ws> Date: Thu, 16 Sep 2010 10:40:31 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2/3] block-nbd: fix use of protocols in backing files and nbd probing References: <1284213896-12705-1-git-send-email-aliguori@us.ibm.com> <1284213896-12705-3-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi On 09/15/2010 11:06 AM, Juan Quintela wrote: > Anthony Liguori wrote: > >> The use of protocols in backing_files is currently broken because of some >> checks for adjusting relative pathnames. >> >> Additionally, there's a spurious read when using an nbd protocol that can be >> quite destructive when using copy-on-read. Potentially, this can lead to >> probing an image file over top of NBD but this is completely wrong as NBD >> devices are not growable. >> >> Signed-off-by: Anthony Liguori >> --- >> NB: this is absolutely not ideal. A more elegant suggestion would be >> appreciated. I don't think NBD cleanly fits the model of a protocol as it >> stands today. >> > Bad, bad boy, you fixed two things in a single patch. > You're not supposed to notice that :-) It was an RFC series, I was really just looking to start a conversation. >> @@ -603,10 +610,16 @@ int bdrv_open(BlockDriverState *bs, const char *filename, int flags, >> BlockDriver *back_drv = NULL; >> >> bs->backing_hd = bdrv_new(""); >> - path_combine(backing_filename, sizeof(backing_filename), >> - filename, bs->backing_file); >> - if (bs->backing_format[0] != '\0') >> - back_drv = bdrv_find_format(bs->backing_format); >> + back_drv = bdrv_find_protocol(bs->backing_file); >> + if (!back_drv) { >> + path_combine(backing_filename, sizeof(backing_filename), >> + filename, bs->backing_file); >> + if (bs->backing_format[0] != '\0') >> + back_drv = bdrv_find_format(bs->backing_format); >> + } else { >> + pstrcpy(backing_filename, sizeof(backing_filename), >> + bs->backing_file); >> + } >> >> /* backing files always opened read-only */ >> back_flags = >> > But this one breaks my setup, I have to backout this patch to be able to > launch guests with qcow2 file images. > Kevin, do you have an opinion about the best way to resolve this? The relative/absolute path is broken for non-file URIs. I think we could mark a protocol as having a file URI type or we could push the absolute/relative conversion down to the file/phys_dev protocol. I think the former approach is probably the least invasive. Regards, Anthony LIguori > Later, Juan. > >