From: Matt Mackall <mpm@selenic.com>
To: Duncan Sands <baldrick@free.fr>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] netpoll endian fixes
Date: Wed, 8 Sep 2004 17:53:35 -0500 [thread overview]
Message-ID: <20040908225334.GN31237@waste.org> (raw)
In-Reply-To: <200409081201.28261.baldrick@free.fr>
On Wed, Sep 08, 2004 at 12:01:28PM +0200, Duncan Sands wrote:
> > 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.
Ok, could you send an updated patch with a Signed-off-by, please?
--
Mathematics is the supreme nostalgia of our time.
next prev parent reply other threads:[~2004-09-08 22:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-07 23:24 Duncan Sands
2004-09-07 23:29 ` Matt Mackall
2004-09-08 6:56 ` Duncan Sands
2004-09-07 23:57 ` Matt Mackall
2004-09-08 10:01 ` Duncan Sands
2004-09-08 22:53 ` Matt Mackall [this message]
2004-09-09 9:31 ` Duncan Sands
[not found] <77423609@toto.iv>
2004-09-09 2:09 ` Peter Chubb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040908225334.GN31237@waste.org \
--to=mpm@selenic.com \
--cc=baldrick@free.fr \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome