[U-Boot] [PATCH 0/57] RFC: Move arch-specific global data into its own structure

[Simon Glass]

Hi,

On Tue, Nov 20, 2012 at 6:06 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Wolfgang,
>
> On Mon, Nov 19, 2012 at 11:25 PM, Wolfgang Denk <wd at denx.de> wrote:
>> Dear Simon Glass,
>>
>> In message <1353100842-20126-1-git-send-email-sjg at chromium.org> you wrote:
>>> The previous generic board series hit a snag in that we needed generic
>>> code to access some of the architecture-specific fields in global_data.
>>
>> I missed that.  Can you please summarize what exactly the problem was,
>> and how this modification is supposed to fix it?
>>
>
> The discussion at the time was here:
>
> http://patchwork.ozlabs.org/patch/146798/
>
> My previous effort to create a generic board init basically fell over
> on this point. Do you agree with the analysis and proposal on that
> thread?

Are there any more comments on this series? A few of the patches need
an update, but I want to figure out if something else needs to be
done.

>
>>> The solution eventually arrived at was to move these fields into a
>>> separate structure, so that global_data has the generic fields,
>>> and within that there is an arch_global_data structure holding the
>>> architecture-specific ones.
>>>
>>> This series makes that change. Assuming this is reasonable, the next
>>> step is to bring back the generic board patches on top of this.
>>
>> This cover letter has a RFC in the subject,. but the following patch
>> series does not.  This is actually bad!
>
> Yes, I added the RFC late and didn't go back and change the rest. I
> have marked them RFC in patchwork.
>
>>
>> General comments / questions:
>>
>> - We always attempted to keep global data as small as possible.  What
>>   happens here appears to be a move in a totally wrong direction.
>>   Instead of simplyfiyng it (and moving stuff out of global data), we
>>   add more and more complexity to it.  That's wrong.  We should not
>>   do that.
>
> It creates a new generic global data which is very simple. For many
> archs this is empty or very short so they will be happy.
>
> The global data is no larger in this series, nor is it any smaller.
>
> I hope that my moving arch-specific things into their own file it will
> help people to simplify things, but if it doesn't then at least it
> doesn't pollute everything else.
>
> I think the complexity you refer to is the introduction of an
> architecture-specific structure within global data, where all the
> arch-specific stuff lives.
>
> This is the solution arrived at on that thread. If this doesn't suit,
> please can you suggest an alternative.
>
>>
>> - The change makes the code less readable.  Reading "gd->arch."
>>   instead of plain "gd->" is no improvements, but rather vice versa.
>>   If we really go this way, this should be improved.
>
> Yes it would be nice. Are you suggesting some sort of macro, or something else?
>
>>
>> - What exactly is the impact of this code changes on the memory
>>   footprint?
>
> We are just moving structure members around a bit, not actually
> changing the function of the code. The series is basically a nop from
> that point of view.
>
> Regards,
> Simon
>
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>> --
>> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>> I'm what passes for a Unix guru in my office. This is  a  frightening
>> concept. - Lee Ann Goldstein, in <3k55ba$c43 at butch.lmsc.lockheed.com>

Regards,
Simon