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

Tom Rini
2013-03-13T18:40:48Z

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@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@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>