[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160715154930.GC3115@twins.programming.kicks-ass.net>
Date: Fri, 15 Jul 2016 17:49:30 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Arnaldo Carvalho de Melo <acme@...hat.com>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Andy Lutomirski <luto@...capital.net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>, linux-next@...r.kernel.org,
linux-kernel@...r.kernel.org,
Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH/RFC] Re: linux-next: build failure after merge of the
luto-misc tree
On Fri, Jul 15, 2016 at 12:43:26PM -0300, Arnaldo Carvalho de Melo wrote:
> Ok, same results, it works, queuing this one, ack?
Sure. Although I'm still somewhat puzzled by the duplicated effort of
__BITS_PER_LONG and BITS_PER_LONG.
> commit a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7
> Author: Peter Zijlstra <peterz@...radead.org>
> Date: Fri Jul 15 12:38:18 2016 -0300
>
> tools: Simplify BITS_PER_LONG define
>
> Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
> reduces the complexity by ditching CONFIG_64BIT, that was being
> synthesized from yet another set of defines, which proved fragile,
> breaking the build on linux-next for no obvious reasons.
If you ever do need to introduce CONFIG_64BIT, __LP64__ seems like the
right symbol to use for it.
Powered by blists - more mailing lists