On Tue, Sep 6, 2022 at 5:00 PM Arnd Bergmann <arnd@xxxxxxxx> 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@xxxxxxxxxx> > > --- > > 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
