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

[Graeme Russ <graeme.russ@gmail.com>]

Hi Tom, Simon, Wolfgang,

On Tue, Dec 4, 2012 at 1:54 AM, Tom Rini <trini@ti.com> wrote:
> On Tue, Nov 20, 2012 at 06:06:30AM -0800, Simon Glass wrote:
>> Hi Wolfgang,
>>
>> On Mon, Nov 19, 2012 at 11:25 PM, Wolfgang Denk <wd@denx.de> wrote:
>> > Dear Simon Glass,
>> >
>> > In message <1353100842-20126-1-git-send-email-sjg@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.
> [snip]
>> > - 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?
>
> Wolfgang?  "global data, architecture specific goo, ..." reads fine and
> helpful to me, honestly.

I've mentioned this before - I think gd is being abused. To me, gd
should contain only data members that are explicitly required prior to
SDRAM being initialised and BSS being available. It has become a bit
of a 'well I need this variable everywhere, I'll dump it in gd'.

To be honest, I think gd should only be a temporary structure used to
carry specific data through the initialisation process up to the point
BSS becomes available. With the 'early malloc' patches in the
pipeline, it might even be possible to malloc the gd structure early
and then when BSS is available, copy the data into the final global
data structure in BSS. I think that would be complicated by functions
that need to use gd both before and after BSS becomes available.

Regards,

Graeme