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

[Arnd Bergmann]

On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
> On Tue, Mar 06, 2012 at 03:49:22PM -0700, mathieu.poirier@xxxxxxxxxx wrote:
> > From: Arnd Bergmann <arnd@xxxxxxxx>
> > 
> > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/