Received-SPF: pass (google.com: domain of linux-kernel+bounces-18183-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240104-syscall_64-v1-1-57fe392ef565@google.com>
In-Reply-To: <20240104-syscall_64-v1-1-57fe392ef565@google.com>
From: Nick Desaulniers <ndesaulniers@google.com>
Date: Fri, 5 Jan 2024 10:11:02 -0800
Message-ID: <CAKwvOdnKi9wABg4YxDocQ_WH0b2n14aiyP_2kfVWadPix=_AJg@mail.gmail.com>
Subject: Re: [PATCH] x86/syscalls: shrink entry/syscall_64.i via IWYU
Cc: Andy Lutomirski <luto@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, 
	Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org, 
	Al Viro <viro@zeniv.linux.org.uk>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 3, 2024 at 4:13=E2=80=AFPM Tanzir Hasan <tanzirh@google.com> wr=
ote:
>
> This diff uses an open source tool include-what-you-use (IWYU) to modify
> the include list, changing indirect includes to direct includes. IWYU is
> implemented using the IWYUScripts github repository which is a tool that
> is currently undergoing development. These changes seek to improve build
> times.
>
> This change to entry/syscall_64.c resulted in a preprocessed size of
> entry/syscall_64.i from 64003 lines to 24509 lines (-62%) for the x86
> defconfig.
>
> Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Tanzir Hasan <tanzirh@google.com>
> ---
>  arch/x86/entry/syscall_64.c | 18 ++++++++++++++----

Generally question to the CC list. Does anyone know //why//
sys_call_table is defined as asmlinkage?

I don't see why `extern "C"` or __attribute__((regparm(0))) would be
necessary here, but maybe I'm missing something?

I don't think that's necessary to refer to //data// defined in C from
inline asm.  Nothing in Documentation mentions this.

And honestly those two seem conflated IMO.  UAPI headers make sense to
use extern C.

assembler defined functions called from C should have regparm set so C
callers know about the i386 calling convention change.

Those seem orthogonal to me; do we ever have cases where BOTH make sense?
--=20
Thanks,
~Nick Desaulniers