linux-kernel - Re: [PATCH 0/3] Change ARCH_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]

Date:	Thu, 3 Nov 2011 23:17:07 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Mike Frysinger <vapier@...too.org>
Cc:	Peter De Schrijver <pdeschrijver@...dia.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Srinidhi Kasagar <srinidhi.kasagar@...ricsson.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	H Hartley Sweeten <hsweeten@...ionengravers.com>,
	David Brown <davidb@...eaurora.org>,
	Rabin Vincent <rabin.vincent@...ricsson.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-sh@...r.kernel.org
Subject: Re: [PATCH 0/3] Change ARCH_NR_GPIO into a Kconfig variable

On Thu, Nov 03, 2011 at 07:07:42PM -0400, Mike Frysinger wrote:
> On Thursday 03 November 2011 18:44:52 Russell King - ARM Linux wrote:
> > It most certainly is an improvement.
> > 
> > One of the things that we (the ARM community as a whole) is focused on to
> > is to reduce the amount of code in arch/arm through consolidation, removing
> > as much duplication as practical between the various SoCs.
> > 
> > One of the other factors that we're also focused on is:
> > (a) reducing the number of configurations which have to be built to
> > properly build-test ARM
> > (b) reducing the number of kernels which have to be built to support a
> >     range of ARM platforms
> 
> i'm aware of these efforts, but i don't see how this Kconfig solution gets you 
> there.  it's still a single define depending on arch-specific knobs.  now, if 
> this were treated as a max value that was based on all the arch needs, it's 
> now useful across SoCs.

(a) you need to read other discussions on this subject which have already
been had on linux-arm-kernel.  Essentially I've had it in the neck for
less than 128 bytes of needless bloat.  So when I'm faced with 8K of
bloat, what do you think my reaction will be?  Roll over and capitulate
only to get it in the neck again?  Or come up with an easy solution?

(b) that's effectively what it is - if you understand what's going on with
the 'default' statements.

For any option, there can be multiple 'default' statements:

- default value: "default" <expr> ["if" <expr>]
  A config option can have any number of default values. If multiple
  default values are visible, only the first defined one is active.
...
  Optionally, dependencies only for this default value can be added with
  "if".

Now, because of that well defined order, if we do this:

config FOO
	int
	default 1024 if A
	default 512 if B
	default 256

Then we end up with this truth table:

A B FOO
n n 256
n y 512
y n 1024
y y 1024

Which - provided the order is highest value first - gets us the highest
value for this variable dependent on which platforms have been selected.

And - given that we don't have many which require this treatment, this
is a sane solution to the problem.  Not only that but it's one which can
be trivially deleted from one file if and when we have sparse gpio.
--
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/