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

[Simon Glass]

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?

>> 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>