From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuiNV-0004XX-Fe for qemu-devel@nongnu.org; Thu, 25 Mar 2010 04:25:21 -0400 Received: from [140.186.70.92] (port=57430 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuiNT-0004Wj-R2 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 04:25:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuiNS-0000fZ-5q for qemu-devel@nongnu.org; Thu, 25 Mar 2010 04:25:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44178) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuiNR-0000fM-Ux for qemu-devel@nongnu.org; Thu, 25 Mar 2010 04:25:18 -0400 Date: Thu, 25 Mar 2010 10:21:32 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: Compile files only once: some planning Message-ID: <20100325082132.GA11221@redhat.com> References: <201003242233.46516.paul@codesourcery.com> <4BAA9732.60909@codemonkey.ws> <201003242305.42950.paul@codesourcery.com> <4BAA9B37.2060609@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BAA9B37.2060609@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , Paul Brook , qemu-devel@nongnu.org On Wed, Mar 24, 2010 at 06:07:35PM -0500, Anthony Liguori wrote: > On 03/24/2010 06:05 PM, Paul Brook wrote: >>> On 03/24/2010 05:33 PM, Paul Brook wrote: >>> >>>>> But now there is a bigger problem, how to pass the property to the >>>>> device. It's not fair to require the user to remember to set it. >>>>> >>>> It should not be a property of the device. All devices have a native >>>> endianness (for PCI this is little-endian), and the intermediate >>>> busses/interconnects should determine whether byteswapping occurs. >>>> >>> Right, the byte swapping needs to happen at the bus level which requires >>> that the PCI regions use a different callback mechanism (and don't >>> register directly with the cpu). >>> >> Not necessarily a different callback mechanism, but probably a different >> registration mechanism. >> > > Problem with the current scheme is that it's tied to target_phys_addr_t. > It's not a target_phys_addr_t and cannot be used with functions that take > target_phys_addr_ts. > > We can either introduce a generic address type or we can introduce bus > specific addresses and have different callbacks. The later has better > type safety and since this isn't an obvious issue to most developers, > that's probably an important feature. > > Regards, > > Anthony Liguori > >> Paul >> I'd prefer a generic address type since this makes it easier to share code: for example virtio devices can use different busses, it's common for pci host bridges to have common code for i/o and memory, etc. -- MST