From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuZg2-0000Up-C7 for qemu-devel@nongnu.org; Wed, 24 Mar 2010 19:07:54 -0400 Received: from [140.186.70.92] (port=57759 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuZg1-0000UL-5o for qemu-devel@nongnu.org; Wed, 24 Mar 2010 19:07:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuZfz-0001IO-Hl for qemu-devel@nongnu.org; Wed, 24 Mar 2010 19:07:52 -0400 Received: from mail-yx0-f191.google.com ([209.85.210.191]:44713) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuZfz-0001II-Br for qemu-devel@nongnu.org; Wed, 24 Mar 2010 19:07:51 -0400 Received: by yxe29 with SMTP id 29so249173yxe.4 for ; Wed, 24 Mar 2010 16:07:50 -0700 (PDT) Message-ID: <4BAA9B37.2060609@codemonkey.ws> Date: Wed, 24 Mar 2010 18:07:35 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Compile files only once: some planning References: <201003242233.46516.paul@codesourcery.com> <4BAA9732.60909@codemonkey.ws> <201003242305.42950.paul@codesourcery.com> In-Reply-To: <201003242305.42950.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Blue Swirl , qemu-devel@nongnu.org, "Michael S. Tsirkin" 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 >