From: Duncan Sands <baldrick@free.fr>
To: Matt Mackall <mpm@selenic.com>
Subject: Re: [PATCH] netpoll endian fixes
Date: Wed, 8 Sep 2004 12:01:28 +0200
User-Agent: KMail/1.6.2
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <200409080124.43530.baldrick@free.fr> <20040907235702.GC31237@waste.org>
In-Reply-To: <20040907235702.GC31237@waste.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200409081201.28261.baldrick@free.fr>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1349
Lines: 32

> It looks like it ought to be 0x45 everywhere, meaning it's currently
> broken everywhere. But no one's complained. Unfortunately at the
> present moment I've got one machine short of a test rig unpacked, so
> I'm loathe to push another fix until I get some other test reports.

Hi Matt, I agree that it should be 0x45 everywhere.  After thinking a bit
I concluded that the

#if defined(__LITTLE_ENDIAN_BITFIELD)
        __u8    ihl:4,
                version:4;
#elif defined (__BIG_ENDIAN_BITFIELD)
        __u8    version:4,
                ihl:4;

in the definition of struct iphdr is to make sure that compiler uses the
first four bits of the byte to refer to version, rather than the last four;
and this only matters when you are accessing the nibbles via the ihl
or version structure fields.  Thus it makes sure that if you write 0x45
to the byte, then version will return 4 and ihl will return 5.  Presumably
the C standard specifies how bitfield expressions should be laid out
in the byte, and ihl:4, version:4; gives opposite results on little-endian
and big-endian machines...

Ciao,

Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/