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

[Tom Rini]

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

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRP2o0AAoJENk4IS6UOR1WbE0QAKZDcVBQZYlWtqSOExpuYBEk
mfCiRw9kyCWDQSsZo9yfqEi2CkPoexZWphqNjI0oCsAemGfh2UeK1Foqlbb3oAS5
A/R2p1zd5eNZbFx9SfUlMr09FhaYwOe1O7PQcHohsCnzU/8yXXAHGe+kz5HePtpU
3R6wZNUjcA7wXGex8o4ygvI8GUctZgDT95hlrdNihrD+TkwQdjmMG3XR2ifz/LrM
I5VXq/9mT/UMvWvrtbpeLGd4VGwYZywrHBAkI0s1GjxQsjGoFfkA1HmZUdS2Hf6x
BzniSGWYypnecWQPhbxetQaRmxUgGolbK2G+JOM5xDHVqUgZJ2zuEeGR9BdBqVGx
slhrI7FNTy2vRmlcYTMoma0q5+gEh+0/YvACXSDNrhySB5y/9Q/pCYFQisvX2ohA
n6IxTGiiQ3SYwvYeLGSx6OLneDzM08IV0nixY0lbPrWKndlPP6lkO+IwjotYcynO
P8fLjXzcTLtU30VkTKchOYt+M6jqMz8eiPgsfifS5CrEll/fPCa9m+ri1/w7O5ZI
zuHN32DlJzdj8DZxoyRsyvED0pUHU1ji4ECzk22ZJ+fcm2uZgLlRvZmzNwIW7zzk
Xmopl2/OCTPl9BDahNxeZCE8Tg6prgBclKQgnLi2hargxPI2L1GUepm0Xm6gdz1H
+IXXBJUL4VGugf8IZPKR
=VwGC
-----END PGP SIGNATURE-----