On Sat, Jun 5, 2010 at 5:39 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
quoted text
> On Sat, 5 Jun 2010, Felipe Contreras wrote:
>>
>> How about instead of using full defconfigs, we use minimal ones and
>> let the rest be determined with defaults.
>
> I wouldn't mind that either, but there needs to be some way to check that
> they _are_ minimal. Which is more complicated than even SAT, afaik.

I don't think so. The SAT should be able to come up with a minimal
config for 'CONFIG_MACH_OMAP3_BEAGLE=y', and then a minimal config for
whatever is in omap3_beagle_defconfig. The diff is either unnecessary,
or the Kconfig files are missing some 'default y if whatever'. You fix
the Kconfig files, and then use the resulting minimal config.

quoted text
> So the reason I don't like the "minimal defconfig" notion is that a
> "regular defconfig" will work equally well, and lazy people will thus not
> bother to make it minimal (because it's work) and instead just pick the
> full config output.
>
> And we're all lazy. So gearing the process towards something that makes it
> easy for lazy cases to do the wrong thing is a bad thing.

Yes, that's why I lean toward the solution that creates an ideal
config with the minimal effort: SAT with a single
CONFIG_MACH_OMAP3_BEAGLE=y. Then you don't need defconfigs at all.

quoted text
> We also don't have any way to "source" these config files from each other,
> so there's no way from within such a config file to say "use the basic
> omap3 defaults an then just add this on top". You can do it by
> concatenating several such files manually from the Makefile or whatever
> script, of course, but then you end up with the files themselves not
> actually describing what they do.

I don't really see the big need for hierarchical configs. When you do
'make ARCH=arm' you are already including all the arm stuff, so
there's no need for an ARM base config. Then you would need some
platform stuff like OMAP3, but if you do CONFIG_ARCH_OMAP3=y, and
there are proper 'default y if ARCH_OMAP3' in the Kconfigs, you don't
need any base config either. The rest of the stuff is truly specific
to the boards.

If there's a need to include other configs, I'm sure we can come with
markups to include them and have a parser script that generates the
.config.

quoted text
> That's why I suggested the Kconfig format instead. It's the exact same
> idea, but it's a "before pre-processing" format that already supports
> including other files.

Yes, although I don't like the format (it looks clearly designed for
something else), it's another possibility. However, I don't think
"allnoconfig" makes sense because that would ignore the default hints
already present in Kconfig files.

-- 
Felipe Contreras
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/