linux-kernel - Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160715162800.GE2523@redhat.com>
Date:	Fri, 15 Jul 2016 13:28:00 -0300
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
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

Em Fri, Jul 15, 2016 at 05:49:30PM +0200, Peter Zijlstra escreveu:
> 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.

Well, I also can't think of something to justify that, would have to dig
deeper to figure out why that duplication was introduced.

Thanks, will queue this one up and be done with it. For the moment. :-)

- Arnaldo
 
> > 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.