From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Mon, 3 Dec 2012 14:19:17 -0800 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> <20121203145414.GE15777@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Graeme, On Mon, Dec 3, 2012 at 2:02 PM, Graeme Russ wrote: > Hi Tom, Simon, Wolfgang, > > On Tue, Dec 4, 2012 at 1:54 AM, Tom Rini 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 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?). > > Regards, > > Graeme Regards, Simon