Date: Fri, 17 Jul 2015 22:56:23 -0500
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Michal Marek <mmarek@suse.cz>,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andi Kleen <andi@firstfloor.org>, Pedro Alves <palves@redhat.com>,
        X86 ML <x86@kernel.org>, live-patching@vger.kernel.org,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in
 aesni-intel_asm.S
Message-ID: <20150718035623.GA22664@treble.redhat.com>
References: <cover.1437150175.git.jpoimboe@redhat.com>
 <2ea0f0602978178eafd012e52b8bdb83cfb159d5.1437150175.git.jpoimboe@redhat.com>
 <20150717194307.GA26757@gmail.com>
 <CALCETrVpVvr+eynj3dtByddY3Efwvuo=KuyMR_=7m3shzY9xyA@mail.gmail.com>
 <20150717203746.GB12761@treble.redhat.com>
 <20150718025116.GB13059@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20150718025116.GB13059@gmail.com>
User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1510
Lines: 37

On Sat, Jul 18, 2015 at 04:51:16AM +0200, Ingo Molnar wrote:
> Note what the names _don't_ contain: that we generate debug info! That fact is not 
> present in the naming, and that's very much intentional, because the precise form 
> of debug info is conditional:
> 
>   - if CONFIG_FRAME_POINTERS=y then we push/pop a stack frame
> 
>   - if (later on) we do CFI annotations we don't push/pop a stack frame but emit 
>     CFI debuginfo

According to current plan, the macro won't add CFI annotations.  That
will be done instead by a separate tool.  So the macro really is frame
pointer specific.

> 
> In that sense 'FRAME' should never be in these names I think, nor 'PROC' (which is 
> not symmetric).
> 
> Plus all 3 variants I suggested are very easy to remember, why I'd always have to 
> look up any non-symmetric macro name called 'PROC'...

The reason I suggested to put FRAME in the macro name is to try to
prevent it from being accidentally used for leaf functions, where it
isn't needed.

Also the naming of FUNCTION_ENTRY and FUNCTION_RETURN doesn't do
anything to distinguish them from the already ubiquitous ENTRY and
ENDPROC.  So as a kernel developer it seems confusing to me, e.g. how do
I remember when to use FUNCTION_ENTRY vs ENTRY?

-- 
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/