[U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL
Scott Wood
scottwood at freescale.com
Tue Mar 12 18:06:53 CET 2013
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.
-Scott
More information about the U-Boot
mailing list