lkml.org 
[lkml]   [2017]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data
From
Date
On 03/03/2017, 07:20 PM, hpa@zytor.com wrote:
> On March 1, 2017 2:27:54 AM PST, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>>> On Wed, 1 Mar 2017, Ingo Molnar wrote:
>>>>
>>>> * Jiri Slaby <jslaby@suse.cz> wrote:
>>>>
>>>>> This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL,
>> END,
>>>>> and other macros across x86. When we have all this sorted out,
>> this will
>>>>> help to inject DWARF unwinding info by objtool later.
>>>>>
>>>>> So, let us use the macros this way:
>>>>> * ENTRY -- start of a global function
>>>>> * ENDPROC -- end of a local/global function
>>>>> * GLOBAL -- start of a globally visible data symbol
>>>>> * END -- end of local/global data symbol
>>>>
>>>> So how about using macro names that actually show the purpose,
>> instead of
>>>> importing all the crappy, historic, essentially randomly chosen
>> debug symbol macro
>>>> names from the binutils and older kernels?
>>>>
>>>> Something sane, like:
>>>>
>>>> SYM__FUNCTION_START
>>>
>>> Sane would be:
>>>
>>> SYM_FUNCTION_START
>>>
>>> The double underscore is just not giving any value.
>>
>> So the double underscore (at least in my view) has two advantages:
>>
>> 1) it helps separate the prefix from the postfix.
>>
>> I.e. it's a 'symbols' namespace, and a 'function start', not the
>> 'start' of a
>> 'symbol function'.
>>
>> 2) It also helps easy greppability.
>>
>> Try this in latest -tip:
>>
>> git grep e820__
>>
>> To see all the E820 API calls - with no false positives!
>>
>> 'git grep e820_' on the other hand is a lot less reliable...
>>
>> But no strong feelings either way, I just try to sneak in these small
>> namespace
>> structure tricks when nobody's looking! ;-)
>>
>> Thanks,
>>
>> Ingo
>
> This seems needlessly verbose to me and clutters the code.
>
> How about:
>
> PROC..ENDPROC, LOCALPROC..ENDPROC and DATA..ENDDATA. Clear, unambiguous and balanced.

I tried this, but:
arch/x86/kernel/relocate_kernel_64.S:27:0: warning: "DATA" redefined
#define DATA(offset) (KEXEC_CONTROL_CODE_MAX_SIZE+(offset))


I am not saying that I cannot fix it up. I just want to say, that these
names might be too generic, especially "PROC" and "DATA". So should I
really stick to these?

thanks,
--
js
suse labs

\
 
 \ /
  Last update: 2017-03-06 15:16    [W:0.149 / U:1.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site