[U-Boot] [PATCH 1/2] ext4: Rename block group descriptor table from gd to bgd

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/03/12 15:59, Graeme Russ wrote:
> Hi Simon,
> 
> On Thu, Oct 4, 2012 at 7:44 AM, Graeme Russ
> <graeme.russ at gmail.com> wrote:
>> Hi Simon,
>> 
>> On Oct 4, 2012 6:58 AM, "Simon Glass" <sjg at chromium.org> wrote:
>>> 
>>> Hi Graeme,
>>> 
>>> On Wed, Oct 3, 2012 at 1:47 PM, Graeme Russ 
>>> <graeme.russ at gmail.com> wrote:
>>>> Hi Simon,
>>>> 
>>>> On Oct 4, 2012 6:40 AM, "Simon Glass" <sjg at chromium.org> 
>>>> wrote:
>>>>> 
>>>>> Hi Tom,
>>>>> 
>>>>> On Wed, Oct 3, 2012 at 1:04 PM, Tom Rini <trini at ti.com> 
>>>>> wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>> 
>>>>>> On 10/03/12 12:53, Simon Glass wrote:
>>>>>> 
>>>>>>> On x86 machines gd is unfortunately a #define, so we 
>>>>>>> should avoid using gd for anything. This patch changes 
>>>>>>> uses of gd to bgd so that ext4fs can be used on x86.
>>>>>>> 
>>>>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>>>> 
>>>>>> Is there any way to change x86 to not be using a #define 
>>>>>> for gd?
>>>>> 
>>>>> I wasn't brave enough to look hard at that, although
>>>>> Graeme is on copy and will know. It is actually using
>>>>> inline assembly to access this special variable.
>>>> 
>>>> Isn't 'gd' used by everyone (global data)? I fail to see how 
>>>> this ever worked.
>>> 
>>> Well only x86 uses a #define for it, so other archs cause no 
>>> problem. It means that we can't use 'gd' as a symbol anywhere 
>>> in U-Boot. I suppose the only sensible use is a structure 
>>> member, as here.
>> 
>> Ah, I see - and I don't see a quick and easy way out. Let me
>> look a bit deeper...
> 
> I remember now... commit 9e6c572ff03cda84c88663b23c7157d8b1f275ac 
> explains why the #define gd came about:
> 
> "Use the base address of the 'F' segment as a pointer to the
> global data structure. By adding the linear address (i.e. the 'D'
> segment address) as the first word of the global data structure,
> the address of the global data relative to the 'D' segment can be
> found simply, for example, by:
> 
> fs movl 0, %eax
> 
> This makes the gd 'pointer' writable prior to relocation (by 
> reloading the Global Desctriptor Table) which brings x86 into line 
> with all other arches
> 
> NOTE: Writing to the gd 'pointer' is expensive (but we only do it 
> twice) but using it to access global data members (read and write) 
> is still fairly cheap"
> 
> The other option was rather ugly - create gd_get() and gd_set() 
> inline functions and replace all instances of gd-> in all U-Boot 
> source with gd_get()-> or gd_set(foo). I don't think it would have 
> made any difference to code size, but the amount of code touched 
> would have been massive.
> 
> The only other option I can think of is to change gd into something
> much less likely to be used as a symbol (__gd for example), but
> again, the patch to do so would be huge
> 
> I'm open to alternatives

OK, we'll just go with re-naming the ext4 part and build-testing
things on x86 more often :)  Thanks for digging up the details!

- -- 
Tom

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

iQIcBAEBAgAGBQJQbMTaAAoJENk4IS6UOR1WWmkP/2eRqqVTtCMwNZ6JP7W/lKDl
bGu2PrIqufPdM2CnQJPpgWWT0PcBIV8thkw5DPhJovjkH7bjFc9bmjXjX6sNZU7V
EnMxU/v6GUdCtM2QKeRv2x7a8iLj2uOcZS4tTg68vA7iD7fj5PwDBTNIGLCSh9EC
VbDo2juPXjz+jSRvuhU7w0MzbeRhwdZ2yACZjlNbnX5TdWam1iXMnxlPPh/pC0Td
ejwy0RuQwHPM7Gxy88b2wIc5DOXn8zoWrqLo1tx8B5S4b6jG+vI8zsFozi4lL9NJ
iCinGd56xDNBIQKPr2NjdpSqkh01efpHqaa7tuBa5mzswNDQikoOXE/ncPFqW618
6kaAHfzCAmSQb/QbwV5576LWw2LcQPGDzz8Mb8iL03nAgHZI8an/blEdJjK6j+1G
EpwzXQ6YkAWnrjCuAMGwfm/ARXai/Qh2YSnT5SPMxIXlWxIfAT7PsBRNbXOLQQp0
M/+NNE25cqAiZqwCxAT/eYR/huJtXbOqOj7GiH9NCn5L8c0Vm3mJ+o+YzRiraNro
D2INZRE1B7347wxb/wkjHlLTfz219RrkSNJE7HBHGPbrtSQOXZaeTa44TZPwZbKP
YuDojx9jMeuVQz1xqAoZECjdIgSEDjNcWcXU6l0JZYQClqDhxtS3GTdnlmMY0kdm
kcZsmBCbojJchtN+VUp8
=0NwK
-----END PGP SIGNATURE-----