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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ