[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <025cfbf4-d5cd-4b06-b86c-8d70f19205df@arm.com>
Date: Mon, 26 Aug 2024 17:55:50 +0200
From: Kevin Brodsky <kevin.brodsky@....com>
To: Jinjie Ruan <ruanjinjie@...wei.com>
Cc: catalin.marinas@....com, will@...nel.org, oleg@...hat.com,
tglx@...utronix.de, peterz@...radead.org, luto@...nel.org, kees@...nel.org,
wad@...omium.org, rostedt@...dmis.org, arnd@...db.de, ardb@...nel.org,
broonie@...nel.org, mark.rutland@....com, rick.p.edgecombe@...el.com,
leobras@...hat.com, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 1/3] entry: Add some arch funcs to support arm64 to use
generic entry
On 22/08/2024 14:36, Jinjie Ruan wrote:
>>> +/**
>>> + * arch_exit_to_kernel_mode_prepare - Architecture specific final work before
>>> + * exit to kernel mode.
>>> + */
>>> +static inline void arch_exit_to_kernel_mode_prepare(struct pt_regs *regs);
>> Any reason to suffix this function with "prepare"? Just
>> arch_exit_to_kernel_mode() seems appropriate (symmetric with
>> arch_enter_from_kernel_mode()).
> prepare means it is the first function before all other exit_to_kernel
> operation in irqentry_exit(), but as the order problem, it can be
> adjusted to the last to aligh with the older arm64 version.
I understand the rationale, but I don't think this aligns very well with
the other hooks - they are generally called after the functions they are
called from, without suggesting where they are called (beginning/end of
the function). In particular we already have
arch_exit_to_user_mode_prepare(), which is named so because it is called
from exit_to_user_mode_prepare(). If we use "prepare" as a suffix here,
I'm concerned we're confusing rather than clarifying things.
Kevin
Powered by blists - more mailing lists