linux-kernel - Re: [PATCH v2 2/2] x86: Support compiling out human-friendly processor feature names

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:	Sun, 23 Feb 2014 13:32:52 -0800
From:	Josh Triplett <josh@...htriplett.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Borislav Petkov <bp@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Feng Tang <feng.tang@...el.com>,
	Ingo Molnar <mingo@...hat.com>,
	Jacob Shin <jacob.shin@....com>,
	Jan Beulich <JBeulich@...e.com>,
	Jussi Kivilinna <jussi.kivilinna@....fi>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Rob Landley <rob@...dley.net>,
	Seiji Aguchi <seiji.aguchi@....com>,
	Stephane Eranian <eranian@...gle.com>,
	Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, x86@...nel.org
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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/