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.
I missed that. Can you please summarize what exactly the problem was, and how this modification is supposed to fix it?
The solution eventually arrived at was to move these fields into a separate structure, so that global_data has the generic fields, and within that there is an arch_global_data structure holding the architecture-specific ones.
This series makes that change. Assuming this is reasonable, the next step is to bring back the generic board patches on top of this.
This cover letter has a RFC in the subject,. but the following patch series does not. This is actually bad!
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.
- 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.
- What exactly is the impact of this code changes on the memory footprint?
Best regards,
Wolfgang Denk