From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LcIMu-0006PY-JG
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 06:56:04 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LcIMt-0006OY-1S
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 06:56:04 -0500
Received: from [199.232.76.173] (port=39344 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LcIMs-0006OU-Rm
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 06:56:02 -0500
Received: from mx20.gnu.org ([199.232.41.8]:38519)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1LcIMs-0008B0-Gi
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 06:56:02 -0500
Received: from mail.codesourcery.com ([65.74.133.4])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1LcIMr-0008Od-8z
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 06:56:01 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [RFC] 64 bit device I/O
Date: Wed, 25 Feb 2009 11:55:57 +0000
References: <49A01839.3090402@earthlink.net>
	<f43fc5580902241216t61a395d6qfddd1a226fd734c7@mail.gmail.com>
	<49A486D1.3000305@earthlink.net>
In-Reply-To: <49A486D1.3000305@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200902251155.58408.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
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: qemu-devel@nongnu.org
Cc: Blue Swirl <blauwirbel@gmail.com>, Robert Reif <reif@earthlink.net>

> > Would it be better to use a structure with four elements with correct
> > types (including uint8/16_t)  instead of the cast? This could also be
> > limited to only cpu_register_io_memory64.
>
> This is what I would prefer and is what the first version of this patch
> that I submitted a year ago did:   http://landley.net/qemu/2008-01-01.html
>
> The problem is that every hardware driver would need to be changed and
> some of them would need to be changed drastically because they use the
> same functions for all three data sizes.

You can always use the same prototype for the first 3 functions. In practice 
there's very little benefit for using types smaller than 32-bit on machines 
capable of runnit qemu.

Paul