From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HNGxn-00009U-3N for qemu-devel@nongnu.org; Fri, 02 Mar 2007 18:14:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HNGxl-00005X-7Z for qemu-devel@nongnu.org; Fri, 02 Mar 2007 18:14:58 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNGxl-00005J-4b for qemu-devel@nongnu.org; Fri, 02 Mar 2007 18:14:57 -0500 Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HNGxk-0006lP-Me for qemu-devel@nongnu.org; Fri, 02 Mar 2007 18:14:56 -0500 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20070302231452.DTIK3103.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com> for ; Fri, 2 Mar 2007 23:14:52 +0000 Received: from miranda.arrow ([213.107.21.212]) by aamtaout03-winn.ispmail.ntl.com with ESMTP id <20070302231452.CKMM26699.aamtaout03-winn.ispmail.ntl.com@miranda.arrow> for ; Fri, 2 Mar 2007 23:14:52 +0000 Received: from sdb by miranda.arrow with local (Exim 4.50) id 1HNGxe-0001lB-8q for qemu-devel@nongnu.org; Fri, 02 Mar 2007 23:14:50 +0000 Date: Fri, 2 Mar 2007 23:14:50 +0000 From: Stuart Brady Subject: Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test Message-ID: <20070302231450.GA6741@miranda.arrow> References: <20070302200949.GD27636@networkno.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070302200949.GD27636@networkno.de> 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 On Fri, Mar 02, 2007 at 08:09:49PM +0000, Thiemo Seufer wrote: > Hello All, > > I changed the pcnet32 driver to get rid of bitfields in its > implementation, now it works also on big endian host systems. I find this curious... C99 (6.7.2.1) says "the allocation order of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation defined". I can't see any requirement for this, so is it just convention that bitfields on big endian systems start from the most significant bit, and those on little endian systems start from the least significant bit? (My thinking is that endianness usually refers to byte ordering and not so much bit ordering.) I ask this because I'd seen some code of the form: #ifdef WORDS_BIGENDIAN typedef struct { int b7:1; int b6:1; int b5:1; int b4:1; int b3:1; int b2:1; int b1:1; int b0:1; } foo; #else typedef struct { int b0:1; int b1:1; int b2:1; int b3:1; int b4:1; int b5:1; int b6:1; int b7:1; } foo; #endif and I had assumed that this was sheer nonsense... > I tested only the 32 bit mode which is used by MIPS/Malta, and > I'm not sure if it still works in Lance mode (as e.g. used on SPARC). > So please test if it still works. I've tried this patch with a SPARC target running Etch, with an i386 host. No problems so far. (FWIW, I have noticed one bug, but it's *not* a problem with this patch. In the Sarge installer, I see "Error while running 'modprobe -v sunlance'". ISTR that if I use the netinstall iso and persist with the installation, Lance works after the reboot. This problem doesn't seem to affect Etch.) Thanks, -- Stuart Brady