From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nikita Kiryanov Date: Mon, 04 Feb 2013 17:07:05 +0200 Subject: [U-Boot] [PATCH 0/5] Create an API for safely accessing BMP header fields In-Reply-To: <20130204151956.0c0e8486@lilith> References: <1359977979-28585-1-git-send-email-nikita@compulab.co.il> <20130204125734.228623e8@lilith> <510FAB72.3050901@compulab.co.il> <20130204151956.0c0e8486@lilith> Message-ID: <510FCE99.3000901@compulab.co.il> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 02/04/2013 04:19 PM, Albert ARIBAUD wrote: > Hi Nikita, > > On Mon, 04 Feb 2013 14:37:06 +0200, Nikita Kiryanov > wrote: > >> Hi Albert, >> >> On 02/04/2013 01:57 PM, Albert ARIBAUD wrote: >>> >>> IIRC, you has submitted a fix so that BMP loads would result in >>> correctly aligned fields and thus no need for accessors. Why this >>> change of mind? >> > >> >> I did mention that I consider that fix as temporary. I believe this fix >> is better because it addresses the issue everywhere and does so in a >> more maintainable way (does not require the address fix to be duplicated >> everywhere there is a problem). > > I actually like the new fix less, as it adds an API where there is no > need of one -- it's not like the implementation of BMP is at risk of > changing. What is the problem in fixing the load address at load time > and then passing this fixed address around? The problem is that it makes the U-Boot display subsystems broken in terms of what kind of programming interface they provide. The load address fix has to be applied in every code path that leads to a BMP being loaded and read in memory. This means that anyone who wants to implement some BMP related functionality needs to care about this architecture/memory issue, and actively circumvent it. This isn't good design. If I'm manipulating BMPs I should only care about my BMPs, not hardware issues. > > Amicalement, > -- Regards, Nikita.