lkml.org 
[lkml]   [2010]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ARM defconfig files
On Thu, 3 Jun 2010, Russell King wrote:
> On Thu, Jun 03, 2010 at 12:49:58PM -0700, Daniel Walker wrote:
> > So your saying it would drop all the selects, but keep the selected
> > options in tact? Or it would just turn off all the selected options?
>
> config MACH_HALIBUT
> bool "Halibut Board (QCT SURF7201A)"
> select I2C if STD_CONFIG
> select I2C_WHATEVER if STD_CONFIG
> ...
>
> That means if you enable STD_CONFIG, you'll get everything that's required
> selected. If you then disable STD_CONFIG, I believe Kconfig leaves
> everything that was selected as still being selected.
>
> So, what you _could_ do is start off with a blank configuration, then
> configure a kernel with STD_CONFIG enabled and you end up with everything
> that's required. If you then want to disable something that's selected,
> turn off STD_CONFIG first, and you'll be able to turn off individual
> options.

I think this certainly makes sense, at least as a proof of concept. If
we end up with lots of

select XYZ if STD_CONFIG

then at that point it might be a good idea to introduce some variations
in the Kconfig language directly. Something like a multi-priority
select statement that would either:

- provide the minimum amount of choice to the user and forcefully
"select" a default set of options expected to enable all features of
the target hardware, or

- let the user see the "preselected" options with a chance to turn it
off, but provide a y by default right away, or

- ignore those "preselect" statement entirely, as some expert mode.

Of course the 2nd and 3rd options wouldn't necessarily mean an optimal
or even working kernel configuration would be produced.


Nicolas


\
 
 \ /
  Last update: 2010-06-03 22:23    [W:1.617 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site