From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NyWxq-0000pZ-FY for qemu-devel@nongnu.org; Sun, 04 Apr 2010 17:02:38 -0400 Received: from [140.186.70.92] (port=57476 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NyWxp-0000pR-C9 for qemu-devel@nongnu.org; Sun, 04 Apr 2010 17:02:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NyWxn-00020v-R5 for qemu-devel@nongnu.org; Sun, 04 Apr 2010 17:02:37 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:53793) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NyWxn-00020m-Kf for qemu-devel@nongnu.org; Sun, 04 Apr 2010 17:02:35 -0400 Received: by pwi6 with SMTP id 6so2435748pwi.4 for ; Sun, 04 Apr 2010 14:02:34 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <201004042130.23957.paul@codesourcery.com> References: <201004042130.23957.paul@codesourcery.com> Date: Mon, 5 Apr 2010 00:02:33 +0300 Message-ID: From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Subject: [Qemu-devel] Re: Revert bogus usb-ohci change List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On 4/4/10, Paul Brook wrote: > Commit f1698408 "Compile usb-ohci only once" introduces a "be" property to the > pci-ohci device. The PCI bus is always little-endian, so this is completely > bogus. A hypothetical big-endian device would actually introduce another > byteswap. Then why there are again byte swaps with big endian target, aren't they bogus too? Because we don't have the byte swapping bus yet. Current system is bogus in this respect, so I claim that in general, the level of bogosity was not changed. > As discussed previously, if you really want to avoid compiling the device > multiple times then this needs to be fixed elsewhere. Adding user visible > properties to devices is definitely not the right solution. > > I have reverted this change. If there are other devices that have been hacked > in the same way then please revert those too. I agree that the user visible property solution was wrong, sorry. I had a patch "Compile rtl8139 and e1000 only once", which had "be" property too but I didn't commit it because the property passing didn't feel right and I didn't have a plan how to pass that from higher levels. Other patches didn't use the property method.