Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

From: Jiri Slaby <jslaby@suse.cz>
To: hpa@zytor.com, Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: mingo@redhat.com, x86@kernel.org, jpoimboe@redhat.com,
	linux-kernel@vger.kernel.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Juergen Gross <jgross@suse.com>,
	xen-devel@lists.xenproject.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	linux-pm@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data
Date: Mon, 6 Mar 2017 15:09:28 +0100	[thread overview]
Message-ID: <0e06bb66-9f48-a925-730b-cf71dd541a3b@suse.cz> (raw)
In-Reply-To: <F37D3EC6-277C-4034-BB6A-B31695ADB358@zytor.com>

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