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

[Wolfgang Denk <wd@denx.de>]

Dear Simon,

In message <CAPnjgZ3QMB+0vcamWAkxF1vvBwzgijAXpDUtBbb7YegEz0pssw@mail.gmail.com> you wrote:
> 
> 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?

Mostly; but some questions have never been really answered, for
example the effect on the memory footprint (i.e. code size).

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

See Graemes other comment...

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

I already did above, and basicly this is what Graeme asks for, too:
instead of adding stuff to GD, we should reduce it to the really
needed bare minimum.  I'm not sure hoch much architecture specific
data would survive such a cleanup.

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

I don;t like the additional level of nesting, nomatter if I have to
write it outt or if it's hidden in some macro (actually I fear tyhe
macro version would be even worse to understand).

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

You add a level of indirecting to the code.  I doubt that goues
without code to load some registers (which in turn will add other code
to push and pop needed registers to/from the stack).

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
"To IBM, 'open' means there is a modicum  of  interoperability  among
some of their equipment."                            - Harv Masterson