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

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/03/12 17:19, Simon Glass wrote:
> Hi Graeme,
> 
> On Mon, Dec 3, 2012 at 2:02 PM, Graeme Russ <graeme.russ@gmail.com>
> wrote:
>> 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.
> 
> 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?).

At the high level, yes, such a cleaning of gd and perhaps even a
re-evaluation of what kind of "global data" structure we need to keep
around for the whole run time is warranted.  And the gd->arch->foo
would be a good place to start looking for shouldn't be in gd at all
candidates.  But that's not a blocker, to me, for this series, since
it will help show the problems.

- -- 
Tom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQvThOAAoJENk4IS6UOR1WWowQALLMLDuRC+YnfTDy0AMPhMCo
iasdqmyQRBBKXU/3o3D6EbOiiYxmmwrWEElJ6E1L3MiJknHz+P0vXJ0ec3DOo1BR
2B7hTMZewiDPGnJ7oREQAFXL2pW1hWKkYPwy/EQwz7RLncKM5+lAfwyuc4c2BFSH
oRYEKglQYCj/VO0H85vuS6BrBKrhdUOzq0AHebaxUnxPX0ZsBCqDesYjxViWVKZy
5Hw3ukqQYFTjl4P3/Ss9IcPkctbp/LWtRpq+vCNLuNee6UHuICz0Ws5wRySsoMpw
AE14EfVXn+N0QsMzm5fWQtCoXDe2J0+UD5qUXnMBUjf3VvlA0OnosHkYl/jOeuu0
oumHcf/YfHvoJpGDuwf2potshB5dlhzLRi4p86Gm/EPpL53zeqKvNJZJEmH70JPd
tKGEMN3RKwPUKzjM8TmaNlGl4HOlxnG4u3qe0DQsAB4rz39z86J/GS0xPzXcuDXO
MFOx+R6bpDtHk6I8YoqiERAReS20ppVi6ktMOUYpysdJjlyIqQ9qUvZChdm7Xx/J
7H7KW3W12z09k+IbexX4Bmv/2m+HNeeN1NgiD10erzFrLxeXZgxSoJ7P+II07aOm
tv483hTErPR0kPS4/oHrfxg1SGEQfCP9c9020RFspVl8ZcoRIuPam8H1RO+Hlzxl
Jhw9kwC54Dlcrthbk9/F
=3MpI
-----END PGP SIGNATURE-----