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

Albert ARIBAUD
2013-03-12T22:07:46Z

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)

Amicalement,
--
Albert.