mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
Cc: linux-kernel@vger.kernel.org,
	Masahiro Yamada <masahiroy@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>, Willy Tarreau <w@1wt.eu>
Subject: [RFC PATCH 0/3] tools/nolibc: install unified multi-arch headers
Date: Fri, 20 Jun 2025 12:37:02 +0200	[thread overview]
Message-ID: <20250620103705.10208-1-w@1wt.eu> (raw)

While the in-tree nolibc directory supports arch auto-detection,
installing it is only performed for a single architecture at once,
requiring as many sysroots as desired architectures. It is not
convenient because external tools rarely expect to change their
include path based on the target.

Furthermore, when installing it along with the UAPI headers for
use with the nolibc toolchains, the issue is reinforced as UAPI
may only be installed for a single architecture, and in this case
we cannot even count on the headers that would have been packaged
along with the compiler and its accompanying libc.

This patchset proposes a convenient approach to satisfy all this.

First, it adds a "headers_all_archs" target to nolibc, that will
install the headers for all supported archs, so that they appear just
like in the original source tree, meaning that when uapi headers are
available (e.g. provided with the toolchain), the build will succeed
for all suppored archs from a single installation directory.

Second, a new "install_all_archs" target iterates over all supported
archs to install the corresponding UAPI headers, and moves each
arch-specific "asm/" subdir to "asm-arch-$arch", then automatically
recreates the files under asm/ to include the corresponding files based
on the detected architecture. This results in a unified sysroot that
can be used by any of the supported architectures without changing the
include path.

I'm marking this as RFC because the operations are entirely performed
inside the nolibc Makefile, and I'm wondering whether there could be
any interest in generalizing the principle and moving it to the
generic uapi installation itself. However I don't see how this could
be easily done in this case, because here we have no other option but
iterate over all supported architectures, and iterating over multiple
archs is not something standard in the kbuild system. But we could also
imagine having a script under scripts/ to install UAPI headers for all
archs at once for example, so ideas are welcome. Of course if there's
no perceived interest in generalizing this to uapi then it can stay
in nolibc where the maintenance cost should remain quite low anyway.

Thanks for any comments!
Willy

--
Willy Tarreau (3):
  tools/nolibc: merge i386 and x86_64 into a single x86 arch
  tools/nolibc: add a new target "headers_all_archs" to loop over all
    archs
  tools/nolibc: add a new "install_all_archs" target

 tools/include/nolibc/Makefile                 |  59 +++++-
 tools/include/nolibc/arch-i386.h              | 178 -----------------
 .../nolibc/{arch-x86_64.h => arch-x86.h}      | 180 +++++++++++++++++-
 tools/include/nolibc/arch.h                   |   6 +-
 4 files changed, 228 insertions(+), 195 deletions(-)
 delete mode 100644 tools/include/nolibc/arch-i386.h
 rename tools/include/nolibc/{arch-x86_64.h => arch-x86.h} (53%)

-- 
2.17.5


             reply	other threads:[~2025-06-20 10:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-20 10:37 Willy Tarreau [this message]
2025-06-20 10:37 ` [RFC PATCH 1/3] tools/nolibc: merge i386 and x86_64 into a single x86 arch Willy Tarreau
2025-06-21  8:29   ` Thomas Weißschuh
2025-06-21  8:44     ` Willy Tarreau
2025-06-20 10:37 ` [RFC PATCH 2/3] tools/nolibc: add a new target "headers_all_archs" to loop over all archs Willy Tarreau
2025-06-23 21:56   ` Thomas Weißschuh
2025-06-24  6:20     ` Willy Tarreau
2025-06-24  7:46       ` Thomas Weißschuh
2025-06-24 10:00         ` Willy Tarreau
2025-06-20 10:37 ` [RFC PATCH 3/3] tools/nolibc: add a new "install_all_archs" target Willy Tarreau
2025-06-26 20:18   ` Thomas Weißschuh
2025-06-26 21:15     ` Arnd Bergmann
2025-06-27  3:25       ` Willy Tarreau
2025-06-27  5:58         ` Arnd Bergmann
2025-06-27  6:07           ` Willy Tarreau
2025-06-27  5:11       ` Thomas Weißschuh
2025-06-27  5:46         ` Willy Tarreau
2025-06-27  5:49           ` Willy Tarreau
2025-06-27  7:27             ` Thomas Weißschuh
2025-06-27  7:29               ` Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250620103705.10208-1-w@1wt.eu \
    --to=w@1wt.eu \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=thomas.weissschuh@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®