From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LcE8p-0005Pw-5A for qemu-devel@nongnu.org; Wed, 25 Feb 2009 02:25:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LcE8o-0005PT-Bc for qemu-devel@nongnu.org; Wed, 25 Feb 2009 02:25:14 -0500 Received: from [199.232.76.173] (port=55615 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LcE8n-0005PM-U5 for qemu-devel@nongnu.org; Wed, 25 Feb 2009 02:25:13 -0500 Received: from mx2.redhat.com ([66.187.237.31]:53640) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LcE8n-00046p-Fp for qemu-devel@nongnu.org; Wed, 25 Feb 2009 02:25:13 -0500 Message-ID: <49A4F272.3010005@redhat.com> Date: Wed, 25 Feb 2009 09:25:38 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] 64 bit device I/O References: <49A01839.3090402@earthlink.net> <49A3ECF9.1050507@earthlink.net> <49A486D1.3000305@earthlink.net> In-Reply-To: <49A486D1.3000305@earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, reif@earthlink.net Cc: Blue Swirl Robert Reif wrote: > Blue Swirl wrote: >> 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. No one seemed interested in > this > approach so I abandoned it. > > This approach while uglier requires no changes to the hardware drivers > unless they need 64 bit support so I hoped it would be better received. You might try adding a struct-based 4-function interface, and implementing the array-based 3-function interface on top of that. This way, no immediate changes would be needed for devices, but we could change them incrementally from the old interface to the new interface. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.