From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCsN1-0007VH-4W for qemu-devel@nongnu.org; Mon, 10 Feb 2014 10:02:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WCsMu-0008TM-PU for qemu-devel@nongnu.org; Mon, 10 Feb 2014 10:02:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCsMu-0008T0-Iq for qemu-devel@nongnu.org; Mon, 10 Feb 2014 10:01:56 -0500 Date: Mon, 10 Feb 2014 16:01:47 +0100 From: Kevin Wolf Message-ID: <20140210150139.GE2832@dhcp-200-207.str.redhat.com> References: <1391881159-13585-1-git-send-email-mreitz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1391881159-13585-1-git-send-email-mreitz@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 0/8] block: Integrate bdrv_file_open() into bdrv_open() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Jeff Cody , qemu-devel@nongnu.org, Stefan Hajnoczi , =?iso-8859-1?Q?Beno=EEt?= Canet Am 08.02.2014 um 18:39 hat Max Reitz geschrieben: > bdrv_file_open() is now nearly a subset of bdrv_open(), except for the > fact that bdrv_file_open() is for protocols and bdrv_open() for block > drivers. It is possible to use bdrv_file_open() with a block driver, but > in that case that block driver must be explicitly specified. > > Due to these great similarities, bdrv_file_open() can be integrated and > made a special case of bdrv_open(). If the flag BDRV_O_PROTOCOL is > specified, bdrv_open() will now do what bdrv_file_open() used to do: > Auto-detecting a protocol instead of a block driver. > > This series implements this and changes all calls to bdrv_file_open() to > bdrv_open() calls with BDRV_O_PROTOCOL specified. > > Note that this flag cannot be discerned automatically since it is > impossible for bdrv_open() to know by itself whether a given file should > be opened with or without the format layer involved: Both are valid > alternatives. Therefore, it still has to be specified by the user. I had two or three comments that can be addressed in a follow-up. Series: Reviewed-by: Kevin Wolf