[U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL

[Tom Rini]

On Tue, Mar 12, 2013 at 11:07:46PM +0100, Albert ARIBAUD wrote:
> Hi Tom,
> 
> On Tue, 12 Mar 2013 13:47:33 -0400, Tom Rini <trini at ti.com> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 03/12/2013 01:19 PM, Albert ARIBAUD wrote:
> > > Hi Scott,
> > > 
> > > On Tue, 12 Mar 2013 12:06:53 -0500, Scott Wood 
> > > <scottwood at freescale.com> wrote:
> > > 
> > >> On 03/12/2013 12:02:56 PM, Tom Rini wrote:
> > >>> On Tue, Mar 12, 2013 at 11:55:22AM -0500, Scott Wood wrote:
> > >>>> On 03/12/2013 10:30:40 AM, Tom Rini wrote:
> > >>>>> On Fri, Mar 08, 2013 at 06:35:04PM -0600, Scott Wood 
> > >>>>> wrote:
> > >>>>>> Why would eliminating all individual callbacks cause 
> > >>>>>> start/end
> > >>> to go
> > >>>>>> away?  If that's the way the list mechanism works, the 
> > >>>>>> mechanism needs fixing.
> > >>>>> 
> > >>>>> Yes, that's how the mechanism works.  Rather than having to
> > >>>>> declare that you expect to have a linker list of name $foo,
> > >>>>> we dynamically determine what linker lists we have and
> > >>>>> setup the linker section entry.
> > >>>> 
> > >>>> So it would break just as hard if we happened to turn off
> > >>>> all of the things that register callbacks.
> > >>>> 
> > >>>>> I'm not sure it's broken exactly, I think maybe we just 
> > >>>>> need to say no env callback support in SPL since it's not 
> > >>>>> really user editable.
> > >>>> 
> > >>>> That's fine, but it's still a bad mechanism.
> > >>> 
> > >>> Yes, the mechanism has a breaking condition on trying to 
> > >>> reference an empty list (which is what SPL ends up with, in 
> > >>> this case).  Poking Albert and Marek in case they have any 
> > >>> ideas, but this seems like a feature not a bug.
> > >> 
> > >> How is it a feature?  One of the main benefit of linker lists is 
> > >> for things to just work when things are configured in/out
> > >> without needing ifdefs and such.  Why should "everything
> > >> configured out" be a special case requiring an ifdef?
> > >> 
> > >> If we want to save some code by ifdeffing the listwalking code 
> > >> for SPL, that's a separate matter.
> > > 
> > > Normally my reworked linker_list code should work fine with some 
> > > code going through an empty list, precisely because list start and 
> > > end symbols, like list entries, are generated by the compiler 
> > > irrespective of one another and then whatever was generated is 
> > > sorted by the linker. So an empty list ends up as two symbols at 
> > > the same address (and indeed, env callbacks, in many boards,
> > > showed this pattern in the map file).
> > 
> > OK, where's the latest/greatest of this re-work?  I'll see if it also
> > solves the problem I have.
> 
> In patchwork (assigned to me, and soon to be applied on u-boot-arm if
> this works for you):
> 
> http://patchwork.ozlabs.org/patch/222904/
> http://patchwork.ozlabs.org/patch/222905/
> http://patchwork.ozlabs.org/patch/222906/
> http://patchwork.ozlabs.org/patch/222908/
> 
> (http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/152754/focus=154634)

For clarity over here, fixed the problem I had so I'll drop 2/2 from
what I posted (1/2 is still applicable as a general thing).  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130313/74df18ce/attachment.pgp>