[ Continuation on the "ARM MSM updates" thread ]
On Thu, 3 Jun 2010, Russell King wrote:
Yeah, the thread started out as a "I got really bored with lots of msm
patches", and then just expanded into what I think is wrong with the
sub-architectures.
I can understand that, but at the same time, I do think that the
"defconfig" file concept as it is now is just broken. To the point of
being unfixable. It's obviously just a copy of the final .config, and it's
fundamentally not really readable (and especially not writable) by humans.
And that all actually made some sense way-back-when, back when it was
originally done - back when our config files were tiny (compared to what
they are now), and when it ended up being the default input for the
config. It just doesn't make much sense any more. The Kconfig files
themselves end up having defaults for the core things, and the non-core
things are too many to list/edit sanely in that format.
So the original reason I want to remove them is that they are very
annoying, but the reasoning that then takes that annoyance and makes me
think seriously about removing them despite the inevitable pain factor is
that I really don't think we can even use the concept for any better
model.
Anything better would _have_ to be totally different. And no, I don't
think your "diffs against a base" model work either, because while it
would make them smaller, it would still make them basically unreadable and
uneditable by any human, which means that it's not something we should
check in - it's a generated file!
And I do think our kernel configurator language already should basically
have the expressive power to do it *sanely*. We already support including
other files, which is a requirement for any hierarchical model.
So I _think_ whatever "mach-xyz" file _should_ do something like
# Kconfig file for OMAP4ABCXYZ chip
.. set the particulars for this _particular_ chip,
ie select the particular drivers on this chip ..
include "chip-family-details" (ie maybe "base OMAP details")
include "architecture-family-details" (ie ARM Kconfig)
see? Not one flat file, and very much not something generated.
And I actually suspect we could do it with our current Kconfig file model.
IOW, in the arch/arm/Kconfig file, I think it should be doable to have
basically a
choice
prompt "ARM platform"
config ARM_PLATFORM_OMAP
bool PLATFORM_OMAP
config ARM_PLATFORM_MSM
bool PLATFORM_MSM
...
endchoice
if ARK_PLATFORM_OMAP
include "Kconfig.omap" # this will further have choices for OMAP versions
elif ARM_PLATFORM_...
and then the individual "Kconfig.platform" files could select certain
options, and then do a "include Kconfig.cpu" which would actually be the
_current_ top-level arch/arm/Kconfig.
Or something. See? Making it hierarchical (so that each individual
Kconfig.xyz file only handles a certain level of detail, and it doesn't
grow unboundedly) and making it fundamentally human readable/writable
would be a really good thing.
NOTE NOTE NOTE! I'm not at all saying it has to be done like the above
with the current Kconfig language. The above is more of a "this is how we
_could_ do it, and it would be a big conceptual improvement".
And I don't think we can get there from here unless I at some point say "I
just removed the xyz_defconfig files", at which point people will curse me
and stumble about until they actually come up with something better.
Of course, if the ARM people do something proactive like the above
_before_ I remove the defconfig files, I won't complain.
Linus
--
