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 09:56:56 -0800
From:	"H. Peter Anvin" <>
To:	Josh Triplett <>
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 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

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


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