From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ly5Xq-0004kM-9E
	for qemu-devel@nongnu.org; Sun, 26 Apr 2009 10:41:26 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ly5Xl-0004iK-Pc
	for qemu-devel@nongnu.org; Sun, 26 Apr 2009 10:41:25 -0400
Received: from [199.232.76.173] (port=33465 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ly5Xl-0004iB-LL
	for qemu-devel@nongnu.org; Sun, 26 Apr 2009 10:41:21 -0400
Received: from verein.lst.de ([213.95.11.210]:38138)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60)
	(envelope-from <hch@lst.de>) id 1Ly5Xl-0001zw-2z
	for qemu-devel@nongnu.org; Sun, 26 Apr 2009 10:41:21 -0400
Date: Sun, 26 Apr 2009 16:41:18 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH] qcow2 corruption: Fix alloc_cluster_link_l2
Message-ID: <20090426144118.GA25792@lst.de>
References: <1239789151-23552-1-git-send-email-kwolf@redhat.com>
	<20090426132444.GA22238@lst.de> <49F46C2B.9060705@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49F46C2B.9060705@redhat.com>
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: Avi Kivity <avi@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, dlaor@redhat.com, Christoph Hellwig <hch@lst.de>, gleb@redhat.com, qemu-devel@nongnu.org

On Sun, Apr 26, 2009 at 05:14:03PM +0300, Avi Kivity wrote:
> Christoph Hellwig wrote:
> >Maybe it's time to make use of sparse's endianess annotations in qcow2
> >to prevent further problems like this one
> 
> I'd much prefer strong type checking at compile time:

sparse has strong typechecking at compiletime for the __bitwise types,
although you need the special sparse compiler to parse the annotations
:)

And the big advantage is that qemu already has the infrastructure for
it, while for your new structs you'd need various new helpers, including
for comparisms of disk endian types, etc.