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

[Simon Glass]

Hi,

On Wed, Oct 3, 2012 at 4:06 PM, Tom Rini <trini at ti.com> wrote:
> -----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!

Sounds good, thank you both.

Regards
Simon

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