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

[Simon Glass]

Hi Graeme,

On Mon, Dec 3, 2012 at 2:02 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Tom, Simon, Wolfgang,
>
> On Tue, Dec 4, 2012 at 1:54 AM, Tom Rini <trini at 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 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.
>> [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.

I mostly agree, but that sounds like an exercise in removing fields
from the gd one by one in the source code. The bit I am not sure of is
whether it is useful for gd to hang around post relocation to provide
access to the data that was decided on early in boot (after all, the
position in memory of gd changes post relocation, so why maintain two
structures for the same info?).

>
> Regards,
>
> Graeme

Regards,
Simon