Date:   Tue, 6 Sep 2022 18:08:07 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <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, Sep 6, 2022 at 5:00 PM 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.
>
> 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.



I wish I had done this before fa96b57c149061f71a70bd6582d995f6424fbbf4.
Maybe I would have been able to avoid loongarch adding a head-y.

When people port a new arch, they mimic other arch implementations,
and apparently they assume having head-y is mandatory, and the right
thing to do.

So, we need something to make arch maintainers realize
"when you add a new head-y entry, very likely you are doing wrong".

So, collecting the current ones into a whitelist can prevent the list
from growing at least, even if nobody strives to reduce it.


I did a similar approach for

  scripts/headers_install.sh
  usr/include/Makefile

It was successful because we did not get a new breakage.




Do you have a better idea to avoid bad code slipping in?




See the next arch port.


If somebody upsteams arch/kvx/, they will be very likely to add
arch/kvx/kernel/head.o to head-y.

They are already doing it.
https://github.com/kalray/linux_coolidge/blob/coolidge/arch/kvx/Makefile




People never re-think "why do we need head-y in the first place?"







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


I prefer a simple list of objects, so that people
can work on it one by one.



As Ard pointed out, we can remove
arch/arm64/kernel/head.o
but it requires deep arch-specific knowledge.



-- 
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists