linux-kernel - Re: [PATCH] x86/Kconfig: Further simplify the NR

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: <20180211104733.fcqt3f7iqsyhzdvw@gmail.com>
Date:   Sun, 11 Feb 2018 11:47:33 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] x86/Kconfig: Further simplify the NR_CPUS config


* Randy Dunlap <rdunlap@...radead.org> wrote:

> On 02/10/2018 02:19 PM, Linus Torvalds wrote:
> > Looks good to me.
> > 
> > At the risk of bike-shedding, we could remove all the
> > 
> >         default    1 if !SMP
> > 
> > from the BEGIN/END/DEFAULT things, and perhaps just keep that part in NR_CPUS.
> > 
> > I didn't check, but I *think* it would work to just do
> > 
> >  config NR_CPUS
> >         int "Maximum number of CPUs" if SMP && !MAXSMP
> >         range NR_CPUS_RANGE_BEGIN NR_CPUS_RANGE_END
> >         default "1" if !SMP
> >         default NR_CPUS_DEFAULT
> > 
> > but maybe the "range" line would need an "if !SMP" on it too to avoid
> > the issue with "1" being out of range.,
> 
> Yeah, I had an early test that failed due to something like that.

I *think* I slightly prefer the current approach, because while it's somewhat 
verbose, the advantage is that this way we have *all* range considerations for a 
given main hardware variant in a single place, and the main NR_CPUS config entry 
is 'passive' in terms of determining the range used.

Plus the verbosity isn't really a problem either, as the whole approach is a 
'verbose' expansion of an overly complex config expression, for better 
readability/maintainability.

Thanks,

	Ingo