Message-ID: <CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=EuA@mail.gmail.com>
Date:   Tue, 6 Sep 2022 10:16:11 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
        Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH v2 8/8] kbuild: remove head-y syntax

On Tue, 6 Sept 2022 at 10:06, Arnd Bergmann <arnd@...db.de> wrote:
>
> 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@...nel.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.
>

Agree with Arnd here - having an exhaustive list that spans all arch/*
subdirectories goes against the divide-and-conquer nature of arch/,
where each architecture manages such things themselves

> 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.
>

For the arm64 case, I seriously doubt whether head.o needs any special
treatment - the layout is section based, and the only piece that must
appear right at the start of the binary image is the image header
(which is emitted into .head.text IIRC), everything else appearing in
head.S is placed in .text, .idmap.text or .init.text, and does not
require any special treatment.

> > +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

Powered by blists - more mailing lists