[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1226680425.5483.9.camel@brick>
Date: Fri, 14 Nov 2008 08:33:45 -0800
From: Harvey Harrison <harvey.harrison@...il.com>
To: Piet Delaney <piet.delaney@...silica.com>
Cc: Chris Zankel <chris@...kel.net>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Marc Gauthier <marc@...silica.com>,
Joe Taylor <joetayloremail@...il.com>,
linux-xtensa@...ux-xtensa.org, Chuck Lever <chuck.lever@...cle.com>
Subject: Re: [PATCH 10/10] xtensa: use the new byteorder headers - Merged
with your previous xtensa-next and will remerge shortly.
On Fri, 2008-11-14 at 00:13 -0800, Piet Delaney wrote:
> Piet Delaney wrote:
> > Harvey Harrison wrote:
> >> On Fri, 2008-11-07 at 19:00 -0800, Piet Delaney wrote:
> >>> Hi Chris:
> >>>
> >>> I've merged your recent xtensa-next with our 2.6.24-smp repo.
> >>> It seems to work fine and I'm in the process of cleaning it
> >>> up a bit and adding preliminary XTENSA kgdb support.
> >>
> >> 2.6.24? In that case you probably don't have include/linux/byteorder.h,
> >> or include/linux/swab.h which would explain your byteorder problems.
> >>
> >> Or is that a typo in the version numbers?
> >
> > I was on 2.6.24 and didn't have a problem compiling the kernel -O0 other
> > than a minor tweak in slab.c. Now in 2.6.27-rc3 I get a compile problem
> > with rpcb_clnt.c at lines 122, 123, and 129:
> >
> > /export/src/xtensa-next/net/sunrpc/rpcb_clnt.c:129: error: (near
> > initialization for 'rpcb_in6addr_loopback.sin6_port')
> >
>
> The problem is fixed by changing htons() to __constant_htons().
> The __constant_*() flavors use a #define and always compile
> to a constant. Ex:
>
> #define ___constant_swab32(x) \
> ((__u32)( \
> (((__u32)(x) & (__u32)0x000000ffUL) << 24) | \
> (((__u32)(x) & (__u32)0x0000ff00UL) << 8) | \
> (((__u32)(x) & (__u32)0x00ff0000UL) >> 8) | \
> (((__u32)(x) & (__u32)0xff000000UL) >> 24) ))
>
> I tried compiling the recent snapshot from Linus's tree and it
> has a new instance of the problem in a common network file.
>
> In this case the recent change was FROM __constant_htons()
> to htons(). See net/core/dev.c`simple_tx_hash():
I find it strange that the net/core/dev.c bits of this commit were
a problem as they were only changing the use inside the case: statements
which had to be constants in the first place and had better be picked
up by the __builtin_constant_p inside swab32().
I believe you said you were compiling at -O0? What compiler?
Harvey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists