From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Tue, 04 Dec 2012 20:17:35 +0100 Subject: [U-Boot] [PATCH 0/57] RFC: Move arch-specific global data into its own structure In-Reply-To: References: <1353100842-20126-1-git-send-email-sjg@chromium.org> <20121120072517.295652003D0@gemini.denx.de> Message-ID: <20121204191735.02BC9201071@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Simon, In message 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