Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932190AbdCFOQl (ORCPT ); Mon, 6 Mar 2017 09:16:41 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36704 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751378AbdCFOQb (ORCPT ); Mon, 6 Mar 2017 09:16:31 -0500 Subject: Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data To: hpa@zytor.com, Ingo Molnar , Thomas Gleixner References: <20170217104757.28588-1-jslaby@suse.cz> <20170301093855.GA27152@gmail.com> <20170301102754.GA13374@gmail.com> Cc: mingo@redhat.com, x86@kernel.org, jpoimboe@redhat.com, linux-kernel@vger.kernel.org, Boris Ostrovsky , Juergen Gross , xen-devel@lists.xenproject.org, "Rafael J. Wysocki" , Len Brown , Pavel Machek , linux-pm@vger.kernel.org, Linus Torvalds , Andrew Morton , Peter Zijlstra From: Jiri Slaby Message-ID: <0e06bb66-9f48-a925-730b-cf71dd541a3b@suse.cz> Date: Mon, 6 Mar 2017 15:09:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2289 Lines: 82 On 03/03/2017, 07:20 PM, hpa@zytor.com wrote: > On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote: >> >> * Thomas Gleixner wrote: >> >>> On Wed, 1 Mar 2017, Ingo Molnar wrote: >>>> >>>> * Jiri Slaby 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