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

[Scott Wood <scottwood@freescale.com>]

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