linux-kernel - Re: [PATCH] ARM: versatile: automatically pick a board in Kconfig

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] [day] [month] [year] [list]

Date:	Fri, 9 Mar 2012 13:44:52 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	"Russell King - ARM Linux" <linux@....linux.org.uk>
Cc:	mathieu.poirier@...aro.org, linux-kernel@...r.kernel.org,
	grant.likely@...retlab.ca
Subject: Re: [PATCH] ARM: versatile: automatically pick a board in Kconfig

On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
> On Tue, Mar 06, 2012 at 03:49:22PM -0700, mathieu.poirier@...aro.org wrote:
> > From: Arnd Bergmann <arnd@...db.de>
> > 
> > The versatile platform supports building any combination of the
> > three board types (AB, PB, DT), but at least one of them has
> > to be enabled. This adds the necessary Kconfig statement to
> > enforce that at least one of the three is selected.
> 
> This approach to 'fixing' the Kconfig doesn't scale particularly well
> when we've got lots of platforms to deal with.
> 
> I much prefer using KALLCONFIG= to seed allno/allyes/allmod/rand configs.
> If you want to target a particular SoC you have to do that anyway.  And
> you have to use that to ensure that you get a sane config state so that
> Kconfig doesn't try and ask for the PHYS_OFFSET value - it will decide
> to make that empty and then refuse to reprocess the Kconfig when you
> try to build the kernel.
> 
> So I don't think there's any point to adding stuff like this.

I don't like the this particular way of working around Kconfig too
much either, but I would really like to see it get resolved in a way
that lets randconfig pick an arbitrary set and still finish the
build. Two other ways to get there that I can see are:

* Add a "multichoice" keyword in Kconfig that lets you write a
list of which at one or more items can be enabled, but not all
disabled. This might be the cleanest solution but it will take
some time to get implemented and have everyone convinced that it's
actually a good idea.

* Remove the ASSERT() for missing machine types, and if possible turn
it into a warning instead. This one would be for you to decide.

I think hardcoding the combination of boards using KCONFIG_ALLCONFIG
is not ideal because that will not fail to catch a lot of real bugs
that I found for unexpected combinations of boards.

	Arnd
--
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/