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