[ Continuation on the "ARM MSM updates" thread ] On Thu, 3 Jun 2010, Russell King wrote: > > It'd be nice if you'd copy me... 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. > On the defconfig files, you may not like them - I don't like the > proliferation of them either. What I've always wanted to see is > one defconfig per class of machines - in other words, one mach-XXX. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
