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  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:	Sun, 23 Feb 2014 13:32:52 -0800
From:	Josh Triplett <>
To:	"H. Peter Anvin" <>
Cc:	Borislav Petkov <>,
	Andrew Morton <>,
	Andi Kleen <>,
	Feng Tang <>,
	Ingo Molnar <>,
	Jacob Shin <>,
	Jan Beulich <>,
	Jussi Kivilinna <>,
	"Kirill A. Shutemov" <>,
	Paul Gortmaker <>,
	Peter Zijlstra <>,
	"Rafael J. Wysocki" <>,
	Rob Landley <>,
	Seiji Aguchi <>,
	Stephane Eranian <>,
	Suravee Suthikulpanit <>,
	Thomas Gleixner <>,,
Subject: Re: [PATCH v2 2/2] x86: Support compiling out human-friendly
 processor feature names

On Sun, Feb 23, 2014 at 09:56:56AM -0800, H. Peter Anvin wrote:
> On 02/22/2014 01:36 PM, Josh Triplett wrote:
> > 
> > No, even after removing the ifdefs around the build rules as you
> > suggested (and v3's fixes for the resulting build issues, notably
> > changing some -y's to -$(CONFIG_X86_FEATURE_NAMES)), the makefiles still
> > manage to not build mkcpustr or cpustr.h, because nothing depends on it.
> How could it miss the rule:
> $(obj)/cpu.o: $(obj)/cpustr.h

Because, in order to un-break the build, v3 wraps an ifdef around that
dependency, to prevent building cpustr.h.  Otherwise, the rule for
cpustr.h tries and fails to build mkcpustr.

> > I could change the build rules to generate an empty cpustr.h and avoid
> > this ifdef, but that'd require an additional ifdef block in the Makefile.
> Typically the way it is done is to generate the #ifdef *inside*
> cpustr.h.  However, cpustr.h is kind of special anyway so it probably
> doesn't matter.

Given that only one file includes cpustr.h, and that seems unlikely to
ever change, moving the ifdef inside the header doesn't seem that
worthwhile.  If it were included more than once, it would definitely
make sense to generate a stub header.

- Josh Triplett
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists