[coreboot] [PATCH] Kill duplicated code in Config.lb

[Carl-Daniel Hailfinger]

On 28.08.2009 14:51, ron minnich wrote:
> On Fri, Aug 28, 2009 at 5:45 AM, Carl-Daniel
> Hailfinger<c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> r4534 introduced devicetree.cb in every mainboard directory, and 100% of
>> that content was extracted from Config.lb in the same directory without
>> eliminating the original contents.
>>
>> This patch fixes the dupliaction by using include statements.
>> So far, I only tackled amd/dbm690t because it's the only target I can
>> run a build+boot test for.
>> Someone needs to fix the other 110 boards in the tree.
>>
>> Boot tested.
>>     
> I would like to NAK this patch.
>   

Given that the move of device trees from Config.lb to devicetree.cb
discarded all comments before the device tree definition, killing
Config.lb will eliminate lots of useful board configuration info. That
means someone has to go through all these files by hand and check for
anything lost in the Config.lb->devicetree.cb copy. One part of my patch
fixed this problem for the amd/dbm690t target. I'll resend that part of
the patch.


> Our intent is that the Config.lb files DIE and be removed. Their
> presence is only useful until such time as we make the cut to Kconfig
> permanent. I would rather not take this patch, as it locks us into
> backwards compatibiility for devicetree.cb -- if we improve sconfig in
> some way,and change devicetree.cb, we have to worry every time we
> change it that our change won't work for the old language. We thus
> have to change the old parser every time we change the new one! This
> is a lot of work for a tool we intend to remove.
>   

Considering the vast config differences between settings of boards
converted to Kconfig and the original settings, I do not think the
cutover will make people so happy.
Here's the diffstat for config changes of Kconfig vs. oldstyle Asus
M2V-MX SE:
118 insertions(+), 112 deletions(-), 49 unchanged

Besides that, Cristi tried to convert amd/dbm690t to Kconfig, but the
result did hang during RAM init. No idea why.

Please don't get me wrong: I'm all for using Kconfig, but it would be
nice to keep the config settings identical during the move because the
config settings are what keeps a board working or breaks it.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/