From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NUkcK-0005T2-I2
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 12:33:20 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NUkcF-0005MA-Mo
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 12:33:19 -0500
Received: from [199.232.76.173] (port=41679 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NUkcF-0005Lr-Hk
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 12:33:15 -0500
Received: from mx1.redhat.com ([209.132.183.28]:48959)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1NUkcE-0000zr-PA
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 12:33:15 -0500
Message-ID: <4B4CB21D.30108@redhat.com>
Date: Tue, 12 Jan 2010 18:32:13 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 2/2] block: untangle open flag manipulation
	in	bdrv_open2
References: <20100111175209.GB7571@lst.de>
In-Reply-To: <20100111175209.GB7571@lst.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christoph Hellwig <hch@lst.de>
Cc: qemu-devel@nongnu.org

Am 11.01.2010 18:52, schrieb Christoph Hellwig:
> Untangle the open flag manipulation in bdrv_open2 and document why we
> are clearing the various flags in the different flag combinations.
> 
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Nice cleanup.

Acked-by: Kevin Wolf <kwolf@redhat.com>

> +        /*
> +         * Currently BDRV_O_CREAT is not supported by any image format,
> +         * but I'm not sure that's reason enough to always clear it for
> +         * the !BDRV_O_FILE case..
> +         */
> +        open_flags &= ~(BDRV_O_CREAT);

Is there even a theoretical use case for this flag? When you want to
create an image, you use bdrv_create. I'd suggest another patch to
remove BDRV_O_CREAT entirely.

Maybe except if we want to support protocols with bdrv_create, so we
would go for the block layer functions rather than the POSIX functions.
However, I don't think there is a need to do so.

Kevin