Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-927-gf4c98c8499-fm-20220826.002-gf4c98c84
Mime-Version: 1.0
Message-Id: <f76020e2-e8bd-4f75-a697-3d6ec6665969@www.fastmail.com>
In-Reply-To: <20220906061313.1445810-9-masahiroy@kernel.org>
References: <20220906061313.1445810-1-masahiroy@kernel.org>
 <20220906061313.1445810-9-masahiroy@kernel.org>
Date:   Tue, 06 Sep 2022 09:59:39 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Masahiro Yamada" <masahiroy@kernel.org>,
        linux-kbuild@vger.kernel.org
Cc:     linux-kernel@vger.kernel.org,
        Linux-Arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH v2 8/8] kbuild: remove head-y syntax
Content-Type: text/plain
Precedence: bulk

On Tue, Sep 6, 2022, at 8:13 AM, Masahiro Yamada wrote:
> Kbuild puts the objects listed in head-y at the head of vmlinux.
> Conventionally, we do this for head*.S, which contains the kernel entry
> point.
>
> A counter approach is to control the section order by the linker script.
> Actually, the code marked as __HEAD goes into the ".head.text" section,
> which is placed before the normal ".text" section.
>
> I do not know if both of them are needed. From the build system
> perspective, head-y is not mandatory. If you can achieve the proper code
> placement by the linker script only, it would be cleaner.
>
> I collected the current head-y objects into head-object-list.txt. It is
> a whitelist. My hope is it will be reduced in the long run.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---

The scripts/head-object-list.txt approach feels a little awkward,
so overall I'm not convinced that this is an improvement as long
as there is no final decision for what should be done instead.

If the .head.text section approach works, maybe convert at
a minimum the x86 and arm64 architectures to provide an example
of what it should look like in the end, otherwise I doubt that
any architecture maintainers are going to work on removing their
architectures from the head-object-list.txt file.

> +arch/alpha/kernel/head.o
> +arch/arc/kernel/head.o
> +arch/arm/kernel/head-nommu.o
> +arch/arm/kernel/head.o
> +arch/arm64/kernel/head.o
> +arch/csky/kernel/head.o
> +arch/hexagon/kernel/head.o
> +arch/ia64/kernel/head.o
> +arch/loongarch/kernel/head.o
> +arch/m68k/68000/head.o
> +arch/m68k/coldfire/head.o
> +arch/m68k/kernel/head.o
> +arch/m68k/kernel/sun3-head.o
> +arch/microblaze/kernel/head.o
> +arch/mips/kernel/head.o
> +arch/nios2/kernel/head.o
> +arch/openrisc/kernel/head.o
> +arch/parisc/kernel/head.o
> +arch/powerpc/kernel/head_40x.o
> +arch/powerpc/kernel/head_44x.o
> +arch/powerpc/kernel/head_64.o
> +arch/powerpc/kernel/head_8xx.o
> +arch/powerpc/kernel/head_book3s_32.o
> +arch/powerpc/kernel/head_fsl_booke.o
> +arch/powerpc/kernel/entry_64.o
> +arch/powerpc/kernel/fpu.o
> +arch/powerpc/kernel/vector.o
> +arch/powerpc/kernel/prom_init.o
> +arch/riscv/kernel/head.o
> +arch/s390/kernel/head64.o
> +arch/sh/kernel/head_32.o
> +arch/sparc/kernel/head_32.o
> +arch/sparc/kernel/head_64.o
> +arch/x86/kernel/head_32.o
> +arch/x86/kernel/head_64.o
> +arch/x86/kernel/head32.o
> +arch/x86/kernel/head64.o
> +arch/x86/kernel/ebda.o
> +arch/x86/kernel/platform-quirks.o
> +arch/xtensa/kernel/head.o

Seeing that almost all of these have the same naming
convention, another alternative would be to have a
special case exclusively for arch/*/kernel/head.S and
make that either an assembly file that includes all
the other files from your current list, or use
an intermediate object to link head-*.o into head.o
before putting that first.

     Arnd