linux-kernel - Re: [RFC PATCH 2/3] tools/nolibc: add a new target "headers_all

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250624100008.GE30919@1wt.eu>
Date: Tue, 24 Jun 2025 12:00:08 +0200
From: Willy Tarreau <w@....eu>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: linux-kernel@...r.kernel.org, Masahiro Yamada <masahiroy@...nel.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [RFC PATCH 2/3] tools/nolibc: add a new target
 "headers_all_archs" to loop over all archs

On Tue, Jun 24, 2025 at 09:46:00AM +0200, Thomas Weißschuh wrote:
> On 2025-06-24 08:20:02+0200, Willy Tarreau wrote:
> > On Mon, Jun 23, 2025 at 11:56:29PM +0200, Thomas Weißschuh wrote:
> > > On 2025-06-20 12:37:04+0200, Willy Tarreau wrote:
> > > > This target allows to install the nolibc headers for all supported
> > > > architectures at once, just like it is in the development tree. This
> > > > is a first step to support full multi-architecture support.
> > > > 
> > > > Signed-off-by: Willy Tarreau <w@....eu>
> > > > ---
> > > >  tools/include/nolibc/Makefile | 10 ++++++++++
> > > >  1 file changed, 10 insertions(+)
> > > > 
> > > > diff --git a/tools/include/nolibc/Makefile b/tools/include/nolibc/Makefile
> > > > index 9197c79b267a4..8de6ac5cec425 100644
> > > > --- a/tools/include/nolibc/Makefile
> > > > +++ b/tools/include/nolibc/Makefile
> > > > @@ -23,6 +23,8 @@ else
> > > >  Q=@
> > > >  endif
> > > >  
> > > > +nolibc_supported_archs := aarch64 arm loongarch m68k mips powerpc riscv s390 sparc x86
> > > > +
> > > >  nolibc_arch := $(patsubst arm64,aarch64,$(ARCH))
> > > >  arch_file := arch-$(nolibc_arch).h
> > > >  all_files := \
> > > > @@ -83,6 +85,7 @@ help:
> > > >  	@echo "  all                 call \"headers\""
> > > >  	@echo "  clean               clean the sysroot"
> > > >  	@echo "  headers             prepare a sysroot in \$${OUTPUT}sysroot"
> > > > +	@echo "  headers_all_archs   prepare a multi-arch sysroot in \$${OUTPUT}sysroot"
> > > >  	@echo "  headers_standalone  like \"headers\", and also install kernel headers"
> > > >  	@echo "  help                this help"
> > > >  	@echo ""
> > > > @@ -110,6 +113,13 @@ headers_standalone: headers
> > > >  	$(Q)$(MAKE) -C $(srctree) headers
> > > >  	$(Q)$(MAKE) -C $(srctree) headers_install INSTALL_HDR_PATH=$(OUTPUT)sysroot
> > > >  
> > > > +# installs headers for all archs at once.
> > > > +headers_all_archs:
> > > > +	$(Q)mkdir -p "$(OUTPUT)sysroot"
> > > > +	$(Q)mkdir -p "$(OUTPUT)sysroot/include"
> > > > +	$(Q)cp --parents $(all_files) arch.h "$(OUTPUT)sysroot/include/"
> > > > +	$(Q)cp $(addsuffix .h,$(addprefix arch-,$(nolibc_supported_archs))) "$(OUTPUT)sysroot/include/"
> > > 
> > > IMO we could always just install all architecture headers.
> > > It's not much code after all.
> > > If it is a problem for a user they can either just delete the
> > > superfluous architectures or do 'mv arch-$foo.h arch.h; rm arch-*.h'.
> > 
> > I wanted to do that first, then thought that maybe some would like
> > to only install the nolibc headers because they already have the
> > UAPI headers from another source (local libc, distro packages,
> > toolchain etc). Even for us during nolibc development, not having
> > to iterate through all archs to reinstall everything is a huge time
> > saver.
> >
> > However, I had another idea that floated in my mind, which is that
> > given that we're only saving a few small arch-* files by not
> > installing all archs all the time, maybe we should replace the
> > "headers" target to always install nolibc headers for all archs
> > like above, and keep the uapi headers install separate (only one
> > or all). This would remove the need for the target above whose
> > role is a bit ambiguous. What do you think ?
> 
> That is exactly what I tried to express :-)

Ah OK, I understood that you wanted to install all UAPI in the target
above :-)  OK that's fine then, will do that.

Willy