[PATCH 00/12] Enable build system on macOS hosts

[PATCH 00/12] Enable build system on macOS hosts

[Daniel Gomez via B4 Relay]

This patch set allows for building the Linux kernel for arm64 in macOS with
LLVM.

Patches are based on previous Nick's work and suggestions [1][2][3] to
enable build system in macOS hosts.

Since macOS does not provide some of the headers available in the GNU
C Library (glibc), the patches include a copy of these headers from
glibc-2.40, with minor modifications detailed in the commit message.

To set up the environment:

* Provide build dependencies (installed via Homebrew):

	coreutils, findutils, gnu-sed, gnu-tar, grep, llvm, make and pkg-config.

* A case sensitive volume for building:

	diskutil apfs addVolume /dev/disk<N> "Case-sensitive APFS" linux

* And include in your PATH all GNU tools required by the Linux kernel as
well as LLVM:

	PATH="/opt/homebrew/opt/coreutils/libexec/gnubin:$PATH"
	PATH="/opt/homebrew/opt/findutils/libexec/gnubin:$PATH"
	PATH="/opt/homebrew/opt/gnu-sed/libexec/gnubin:$PATH"
	PATH="/opt/homebrew/opt/gnu-tar/libexec/gnubin:$PATH"
	PATH="/opt/homebrew/opt/grep/libexec/gnubin:$PATH"
	PATH="/opt/homebrew/opt/make/libexec/gnubin:$PATH"
	PATH="/opt/homebrew/opt/llvm/bin:$PATH"

* Start the build using LLVM:

	make LLVM=1 allyesconfig
	make LLVM=1 -j$(nproc)

I believe other architectures could also be supported if we can move
forward this initiative. Additionally, we could incorporate Rust
support. I understand that Finn Behrens has some patches [4][5] based on
Nick's previous work.

[1]: WIP: build Linux on MacOS
https://github.com/ClangBuiltLinux/linux/commit/f06333e29addbc3d714adb340355f471c1dfe95a

[2] Subject: [PATCH] scripts: subarch.include: fix SUBARCH on MacOS hosts
https://lore.kernel.org/all/20221113233812.36784-1-nick.desaulniers@gmail.com/

[3] Subject: Any interest in building the Linux kernel from a MacOS host?
https://lore.kernel.org/all/CAH7mPvj64Scp6_Nbaj8KOfkoV5f7_N5L=Tv5Z9zGyn5SS+gsUw@mail.gmail.com/

[4] https://github.com/kloenk/linux/commits/rust-project_macos-dylib/

[5] https://kloenk.eu/posts/build-linux-on-m1-macos/

To: Masahiro Yamada <masahiroy@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
To: Nicolas Schier <nicolas@fjasle.eu>
To: Lucas De Marchi <lucas.demarchi@intel.com>
To: Thomas Hellström <thomas.hellstrom@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Maxime Ripard <mripard@kernel.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
To: David Airlie <airlied@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
To: William Hubbs <w.d.hubbs@gmail.com>
To: Chris Brannon <chris@the-brannons.com>
To: Kirk Reiser <kirk@reisers.ca>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Paul Moore <paul@paul-moore.com>
To: Stephen Smalley <stephen.smalley.work@gmail.com>
To: Ondrej Mosnacek <omosnace@redhat.com>
To: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
To: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
To: James Morse <james.morse@arm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Zenghui Yu <yuzenghui@huawei.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jiri Slaby <jirislaby@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
To: Bill Wendling <morbo@google.com>
To: Justin Stitt <justinstitt@google.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Cc: intel-xe@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: speakup@linux-speakup.org
Cc: selinux@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: kvmarm@lists.linux.dev
Cc: linux-serial@vger.kernel.org
Cc: llvm@lists.linux.dev
Cc: Finn Behrens <me@kloenk.dev>
Cc: Daniel Gomez (Samsung) <d+samsung@kruces.com>
Cc: gost.dev@samsung.com

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
Daniel Gomez (11):
      kbuild: add header_install dependency to scripts
      file2alias: fix uuid_t definitions for macos
      drm/xe: xe_gen_wa_oob: fix program_invocation_short_name for macos
      accessiblity/speakup: genmap and makemapdata require linux/version.h
      selinux/genheaders: include bitsperlong and posix_types headers
      selinux/mdp: include bitsperlong and posix_types headers
      include: add elf.h support
      include: add endian.h support
      scripts/mod: add byteswap support
      tty/vt: conmakehash requires linux/limits.h
      scripts/kallsyms: add compatibility support for macos

Nick Desaulniers (1):
      scripts: subarch.include: fix SUBARCH on MacOS hosts

 Makefile                               |    2 +-
 arch/arm64/kernel/pi/Makefile          |    1 +
 arch/arm64/kernel/vdso32/Makefile      |    1 +
 arch/arm64/kvm/hyp/nvhe/Makefile       |    2 +-
 drivers/accessibility/speakup/Makefile |    2 +
 drivers/gpu/drm/xe/xe_gen_wa_oob.c     |    8 +-
 drivers/tty/vt/Makefile                |    1 +
 include/byteswap/byteswap.h            |   35 +
 include/elf/elf.h                      | 4491 ++++++++++++++++++++++++++++++++
 include/endian/bits/uintn-identity.h   |   48 +
 include/endian/endian.h                |   63 +
 scripts/Makefile                       |    3 +-
 scripts/kallsyms.c                     |    4 +
 scripts/mod/Makefile                   |    6 +
 scripts/mod/file2alias.c               |    3 +
 scripts/selinux/genheaders/Makefile    |    3 +-
 scripts/selinux/mdp/Makefile           |    3 +-
 scripts/subarch.include                |    3 +-
 18 files changed, 4672 insertions(+), 7 deletions(-)
---
base-commit: 1e391b34f6aa043c7afa40a2103163a0ef06d179
change-id: 20240807-macos-build-support-9ca0d77adb17

Best regards,
-- 
Daniel Gomez <da.gomez@samsung.com>

[PATCH 01/12] scripts: subarch.include: fix SUBARCH on MacOS hosts

[Daniel Gomez via B4 Relay]

From: Nick Desaulniers <nick.desaulniers@gmail.com>

When building the Linux kernel on an aarch64 MacOS based host, if we don't
specify a value for ARCH when invoking make, we default to arm and thus
multi_v7_defconfig rather than the expected arm64 and arm64's defconfig.

This is because subarch.include invokes `uname -m` which on MacOS hosts
evaluates to `arm64` but on Linux hosts evaluates to `aarch64`,

This allows us to build ARCH=arm64 natively on MacOS (as in ARCH need
not be specified on an aarch64-based system).

Utilize a negative lookahead regular expression to avoid matching arm64.

Add a separate expression to support for armv.* as per error reported by
Nicolas Schier [1].

[1] https://lore.kernel.org/all/Y3MRvtwdjIwMHvRo@bergen.fjasle.eu/#t

Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 scripts/subarch.include | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/subarch.include b/scripts/subarch.include
index 4bd327d0ae42..5d84ad8c0dee 100644
--- a/scripts/subarch.include
+++ b/scripts/subarch.include
@@ -6,7 +6,8 @@
 
 SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
 				  -e s/sun4u/sparc64/ \
-				  -e s/arm.*/arm/ -e s/sa110/arm/ \
+				  -e s/armv.*/arm/ \
+				  -e s/arm\(?:\(?!64\).*\)/arm/ -e s/sa110/arm/ \
 				  -e s/s390x/s390/ \
 				  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
 				  -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \

-- 
Git-146)

Re: [PATCH 01/12] scripts: subarch.include: fix SUBARCH on MacOS hosts

[Nicolas Schier]

On Wed, Aug 07, 2024 at 01:09:15AM +0200, Daniel Gomez via B4 Relay wrote:
> From: Nick Desaulniers <nick.desaulniers@gmail.com>
> 
> When building the Linux kernel on an aarch64 MacOS based host, if we don't
> specify a value for ARCH when invoking make, we default to arm and thus
> multi_v7_defconfig rather than the expected arm64 and arm64's defconfig.
> 
> This is because subarch.include invokes `uname -m` which on MacOS hosts
> evaluates to `arm64` but on Linux hosts evaluates to `aarch64`,
> 
> This allows us to build ARCH=arm64 natively on MacOS (as in ARCH need
> not be specified on an aarch64-based system).
> 
> Utilize a negative lookahead regular expression to avoid matching arm64.
> 
> Add a separate expression to support for armv.* as per error reported by
> Nicolas Schier [1].
> 
> [1] https://lore.kernel.org/all/Y3MRvtwdjIwMHvRo@bergen.fjasle.eu/#t
> 
> Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
>  scripts/subarch.include | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/subarch.include b/scripts/subarch.include
> index 4bd327d0ae42..5d84ad8c0dee 100644
> --- a/scripts/subarch.include
> +++ b/scripts/subarch.include
> @@ -6,7 +6,8 @@
>  
>  SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
>  				  -e s/sun4u/sparc64/ \
> -				  -e s/arm.*/arm/ -e s/sa110/arm/ \
> +				  -e s/armv.*/arm/ \
> +				  -e s/arm\(?:\(?!64\).*\)/arm/ -e s/sa110/arm/ \
>  				  -e s/s390x/s390/ \
>  				  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
>  				  -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
> 

Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

Re: [PATCH 01/12] scripts: subarch.include: fix SUBARCH on MacOS hosts

[Masahiro Yamada]

On Wed, Aug 7, 2024 at 8:10 AM Daniel Gomez via B4 Relay
<devnull+da.gomez.samsung.com@kernel.org> wrote:
>
> From: Nick Desaulniers <nick.desaulniers@gmail.com>
>
> When building the Linux kernel on an aarch64 MacOS based host, if we don't
> specify a value for ARCH when invoking make, we default to arm and thus
> multi_v7_defconfig rather than the expected arm64 and arm64's defconfig.
>
> This is because subarch.include invokes `uname -m` which on MacOS hosts
> evaluates to `arm64` but on Linux hosts evaluates to `aarch64`,
>
> This allows us to build ARCH=arm64 natively on MacOS (as in ARCH need
> not be specified on an aarch64-based system).
>
> Utilize a negative lookahead regular expression to avoid matching arm64.


Does sed support "negative lookahead regular expression"?

>
> Add a separate expression to support for armv.* as per error reported by
> Nicolas Schier [1].
>
> [1] https://lore.kernel.org/all/Y3MRvtwdjIwMHvRo@bergen.fjasle.eu/#t
>
> Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
>  scripts/subarch.include | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/subarch.include b/scripts/subarch.include
> index 4bd327d0ae42..5d84ad8c0dee 100644
> --- a/scripts/subarch.include
> +++ b/scripts/subarch.include
> @@ -6,7 +6,8 @@
>
>  SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
>                                   -e s/sun4u/sparc64/ \
> -                                 -e s/arm.*/arm/ -e s/sa110/arm/ \
> +                                 -e s/armv.*/arm/ \
> +                                 -e s/arm\(?:\(?!64\).*\)/arm/ -e s/sa110/arm/ \


s/arm\(?:\(?!64\).*\)/arm/

In sed, this expression does not seem to match anything.

(or please give me some matching examples if I miss something)





Nocolas already provided correct code:

> [1] https://lore.kernel.org/all/Y3MRvtwdjIwMHvRo@bergen.fjasle.eu/#t






>                                   -e s/s390x/s390/ \
>                                   -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
>                                   -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
>
> --
> Git-146)
>
>


--
Best Regards


Masahiro Yamada

Re: [PATCH 01/12] scripts: subarch.include: fix SUBARCH on MacOS hosts

[Daniel Gomez (Samsung)]

On Fri, Aug 23, 2024 at 6:13 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Wed, Aug 7, 2024 at 8:10 AM Daniel Gomez via B4 Relay
> <devnull+da.gomez.samsung.com@kernel.org> wrote:
> >
> > From: Nick Desaulniers <nick.desaulniers@gmail.com>
> >
> > When building the Linux kernel on an aarch64 MacOS based host, if we don't
> > specify a value for ARCH when invoking make, we default to arm and thus
> > multi_v7_defconfig rather than the expected arm64 and arm64's defconfig.
> >
> > This is because subarch.include invokes `uname -m` which on MacOS hosts
> > evaluates to `arm64` but on Linux hosts evaluates to `aarch64`,
> >
> > This allows us to build ARCH=arm64 natively on MacOS (as in ARCH need
> > not be specified on an aarch64-based system).
> >
> > Utilize a negative lookahead regular expression to avoid matching arm64.
>
>
> Does sed support "negative lookahead regular expression"?

I think they removed support for PCRE. I've found this:

commit 261c7f145d015d9acb79dc650d27e4a23b839c23
Author: Assaf Gordon <assafgordon@gmail.com>
Date:   Tue Aug 21 14:25:57 2018 -0600

    maint: remove REG_PERL code

    Perl-regexp syntax (PCRE) in GNU Sed is shelved indefinitely.
    See https://bugs.gnu.org/22801 , https://bugs.gnu.org/22647 .
    Remove all (unused) REG_PERL related code.

    * sed/sed.c, sed/sed.h, sed/regexp.c, sed/compile.c: Remove REG_PERL code.

git tag --contains 261c7f145d015d9acb79dc650d27e4a23b839c23
v4.6
v4.7
v4.8
v4.9

And my sed version is (Debian):

sed --version
sed (GNU sed) 4.9
Packaged by Debian
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Jay Fenlason, Tom Lord, Ken Pizzini,
Paolo Bonzini, Jim Meyering, and Assaf Gordon.

This sed program was built with SELinux support.
SELinux is disabled on this system.

GNU sed home page: <https://www.gnu.org/software/sed/>.
General help using GNU software: <https://www.gnu.org/gethelp/>.
E-mail bug reports to: <bug-sed@gnu.org>.

sed version (Homebrew):
sed --version
sed (GNU sed) 4.9
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Jay Fenlason, Tom Lord, Ken Pizzini,
Paolo Bonzini, Jim Meyering, and Assaf Gordon.

This sed program was built without SELinux support.

GNU sed home page: <https://www.gnu.org/software/sed/>.
General help using GNU software: <https://www.gnu.org/gethelp/>.
E-mail bug reports to: <bug-sed@gnu.org>.

>
> >
> > Add a separate expression to support for armv.* as per error reported by
> > Nicolas Schier [1].
> >
> > [1] https://lore.kernel.org/all/Y3MRvtwdjIwMHvRo@bergen.fjasle.eu/#t
> >
> > Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
> > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > ---
> >  scripts/subarch.include | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/subarch.include b/scripts/subarch.include
> > index 4bd327d0ae42..5d84ad8c0dee 100644
> > --- a/scripts/subarch.include
> > +++ b/scripts/subarch.include
> > @@ -6,7 +6,8 @@
> >
> >  SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> >                                   -e s/sun4u/sparc64/ \
> > -                                 -e s/arm.*/arm/ -e s/sa110/arm/ \
> > +                                 -e s/armv.*/arm/ \
> > +                                 -e s/arm\(?:\(?!64\).*\)/arm/ -e s/sa110/arm/ \
>
>
> s/arm\(?:\(?!64\).*\)/arm/
>
> In sed, this expression does not seem to match anything.

You are correct. I've removed the expression and saw no difference.
See below with my test case:
>
> (or please give me some matching examples if I miss something)

cat Makefile
MACHINE ?= "aarch64"
SUBARCH0 := $(shell echo $(MACHINE) | sed \
                                  -e s/arm.*/arm/ \
                                  -e s/aarch64.*/arm64/)

SUBARCH1 := $(shell echo $(MACHINE) | sed \
                                  -e s/armv.*/arm/ \
                                  -e s/aarch64.*/arm64/)

SUBARCH2 := $(shell echo $(MACHINE) | sed \
                                  -e /^arm64$/!s/arm.*/arm/ \
                                  -e s/aarch64.*/arm64/)

test:
        @echo "MACHINE=$(MACHINE)"
        @echo "SUBARCH0=$(SUBARCH0)"
        @echo "SUBARCH1=$(SUBARCH1)"
        @echo "SUBARCH2=$(SUBARCH2)"
        @echo "---"

SUBARCH0 represents the current upstream expressions for arm/arm64.
SUBARCH1 is my proposal in case we need to cover only armv* for 32-bit
arm (I think that is incomplete?) and SUBARCH2 is Nicolas' proposal
(which I can't make it work in the test Makefile).

Running the above Makefile, I get:

make test MACHINE=armv4 && make test MACHINE=arm7 && make test
MACHINE=armhf && make test MACHINE=aarch64 && make test MACHINE=arm64
MACHINE=armv4
SUBARCH0=arm
SUBARCH1=arm
SUBARCH2=armv4
---
MACHINE=arm7
SUBARCH0=arm
SUBARCH1=arm7
SUBARCH2=arm7
---
MACHINE=armhf
SUBARCH0=arm
SUBARCH1=armhf
SUBARCH2=armhf
---
MACHINE=aarch64
SUBARCH0=arm64
SUBARCH1=arm64
SUBARCH2=arm64
---
MACHINE=arm64
SUBARCH0=arm
SUBARCH1=arm64
SUBARCH2=arm64
---
>
>
>
>
>
> Nocolas already provided correct code:
>
> > [1] https://lore.kernel.org/all/Y3MRvtwdjIwMHvRo@bergen.fjasle.eu/#t

I think it is even more simple if we just make this change:

-                                 -e s/arm.*/arm/ -e s/sa110/arm/ \
+                                 -e s/armv.*/arm/ \

Does armv.* cover all arm32 machines? I see armhf, arm7, arm8 and
armv*, is it correct?

And thanks for checking!

>
>
>
>
>
>
> >                                   -e s/s390x/s390/ \
> >                                   -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> >                                   -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
> >
> > --
> > Git-146)
> >
> >
>
>
> --
> Best Regards
>
>
> Masahiro Yamada

Re: [PATCH 01/12] scripts: subarch.include: fix SUBARCH on MacOS hosts

[Daniel Gomez (Samsung)]

On Sat, Aug 24, 2024 at 12:14 AM Daniel Gomez (Samsung)
<d+samsung@kruces.com> wrote:
>
> On Fri, Aug 23, 2024 at 6:13 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Wed, Aug 7, 2024 at 8:10 AM Daniel Gomez via B4 Relay
> > <devnull+da.gomez.samsung.com@kernel.org> wrote:
> > >
> > > From: Nick Desaulniers <nick.desaulniers@gmail.com>
> > >
> > > When building the Linux kernel on an aarch64 MacOS based host, if we don't
> > > specify a value for ARCH when invoking make, we default to arm and thus
> > > multi_v7_defconfig rather than the expected arm64 and arm64's defconfig.
> > >
> > > This is because subarch.include invokes `uname -m` which on MacOS hosts
> > > evaluates to `arm64` but on Linux hosts evaluates to `aarch64`,
> > >
> > > This allows us to build ARCH=arm64 natively on MacOS (as in ARCH need
> > > not be specified on an aarch64-based system).
> > >
> > > Utilize a negative lookahead regular expression to avoid matching arm64.
> >
> >
> > Does sed support "negative lookahead regular expression"?
>
> I think they removed support for PCRE. I've found this:
>
> commit 261c7f145d015d9acb79dc650d27e4a23b839c23
> Author: Assaf Gordon <assafgordon@gmail.com>
> Date:   Tue Aug 21 14:25:57 2018 -0600
>
>     maint: remove REG_PERL code
>
>     Perl-regexp syntax (PCRE) in GNU Sed is shelved indefinitely.
>     See https://bugs.gnu.org/22801 , https://bugs.gnu.org/22647 .
>     Remove all (unused) REG_PERL related code.
>
>     * sed/sed.c, sed/sed.h, sed/regexp.c, sed/compile.c: Remove REG_PERL code.
>
> git tag --contains 261c7f145d015d9acb79dc650d27e4a23b839c23
> v4.6
> v4.7
> v4.8
> v4.9
>
> And my sed version is (Debian):
>
> sed --version
> sed (GNU sed) 4.9
> Packaged by Debian
> Copyright (C) 2022 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by Jay Fenlason, Tom Lord, Ken Pizzini,
> Paolo Bonzini, Jim Meyering, and Assaf Gordon.
>
> This sed program was built with SELinux support.
> SELinux is disabled on this system.
>
> GNU sed home page: <https://www.gnu.org/software/sed/>.
> General help using GNU software: <https://www.gnu.org/gethelp/>.
> E-mail bug reports to: <bug-sed@gnu.org>.
>
> sed version (Homebrew):
> sed --version
> sed (GNU sed) 4.9
> Copyright (C) 2022 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by Jay Fenlason, Tom Lord, Ken Pizzini,
> Paolo Bonzini, Jim Meyering, and Assaf Gordon.
>
> This sed program was built without SELinux support.
>
> GNU sed home page: <https://www.gnu.org/software/sed/>.
> General help using GNU software: <https://www.gnu.org/gethelp/>.
> E-mail bug reports to: <bug-sed@gnu.org>.
>
> >
> > >
> > > Add a separate expression to support for armv.* as per error reported by
> > > Nicolas Schier [1].
> > >
> > > [1] https://lore.kernel.org/all/Y3MRvtwdjIwMHvRo@bergen.fjasle.eu/#t
> > >
> > > Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
> > > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > > ---
> > >  scripts/subarch.include | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/subarch.include b/scripts/subarch.include
> > > index 4bd327d0ae42..5d84ad8c0dee 100644
> > > --- a/scripts/subarch.include
> > > +++ b/scripts/subarch.include
> > > @@ -6,7 +6,8 @@
> > >
> > >  SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> > >                                   -e s/sun4u/sparc64/ \
> > > -                                 -e s/arm.*/arm/ -e s/sa110/arm/ \
> > > +                                 -e s/armv.*/arm/ \
> > > +                                 -e s/arm\(?:\(?!64\).*\)/arm/ -e s/sa110/arm/ \
> >
> >
> > s/arm\(?:\(?!64\).*\)/arm/
> >
> > In sed, this expression does not seem to match anything.
>
> You are correct. I've removed the expression and saw no difference.
> See below with my test case:
> >
> > (or please give me some matching examples if I miss something)
>
> cat Makefile
> MACHINE ?= "aarch64"
> SUBARCH0 := $(shell echo $(MACHINE) | sed \
>                                   -e s/arm.*/arm/ \
>                                   -e s/aarch64.*/arm64/)
>
> SUBARCH1 := $(shell echo $(MACHINE) | sed \
>                                   -e s/armv.*/arm/ \
>                                   -e s/aarch64.*/arm64/)
>
> SUBARCH2 := $(shell echo $(MACHINE) | sed \
>                                   -e /^arm64$/!s/arm.*/arm/ \
>                                   -e s/aarch64.*/arm64/)
>
> test:
>         @echo "MACHINE=$(MACHINE)"
>         @echo "SUBARCH0=$(SUBARCH0)"
>         @echo "SUBARCH1=$(SUBARCH1)"
>         @echo "SUBARCH2=$(SUBARCH2)"
>         @echo "---"
>
> SUBARCH0 represents the current upstream expressions for arm/arm64.
> SUBARCH1 is my proposal in case we need to cover only armv* for 32-bit
> arm (I think that is incomplete?) and SUBARCH2 is Nicolas' proposal
> (which I can't make it work in the test Makefile).

To make Nicolas's expression work in Makefile I just need to pass 2 $ like this:

diff -u Makefile.old Makefile
--- Makefile.old  2024-08-24 21:25:28.525267566 +0200
+++ Makefile    2024-08-24 21:28:32.640477991 +0200
@@ -8,7 +8,7 @@
                                  -e s/aarch64.*/arm64/)

 SUBARCH2 := $(shell echo $(MACHINE) | sed \
-                                 -e /^arm64$/!s/arm.*/arm/ \
+                                 -e /^arm64$$/!s/arm.*/arm/ \
                                  -e s/aarch64.*/arm64/)

 test:

And all test cases passed. So, I will include this change for v2.

>
> Running the above Makefile, I get:
>
> make test MACHINE=armv4 && make test MACHINE=arm7 && make test
> MACHINE=armhf && make test MACHINE=aarch64 && make test MACHINE=arm64
> MACHINE=armv4
> SUBARCH0=arm
> SUBARCH1=arm
> SUBARCH2=armv4
> ---
> MACHINE=arm7
> SUBARCH0=arm
> SUBARCH1=arm7
> SUBARCH2=arm7
> ---
> MACHINE=armhf
> SUBARCH0=arm
> SUBARCH1=armhf
> SUBARCH2=armhf
> ---
> MACHINE=aarch64
> SUBARCH0=arm64
> SUBARCH1=arm64
> SUBARCH2=arm64
> ---
> MACHINE=arm64
> SUBARCH0=arm
> SUBARCH1=arm64
> SUBARCH2=arm64
> ---
> >
> >
> >
> >
> >
> > Nocolas already provided correct code:
> >
> > > [1] https://lore.kernel.org/all/Y3MRvtwdjIwMHvRo@bergen.fjasle.eu/#t
>
> I think it is even more simple if we just make this change:
>
> -                                 -e s/arm.*/arm/ -e s/sa110/arm/ \
> +                                 -e s/armv.*/arm/ \
>
> Does armv.* cover all arm32 machines? I see armhf, arm7, arm8 and
> armv*, is it correct?
>
> And thanks for checking!
>
> >
> >
> >
> >
> >
> >
> > >                                   -e s/s390x/s390/ \
> > >                                   -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> > >                                   -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
> > >
> > > --
> > > Git-146)
> > >
> > >
> >
> >
> > --
> > Best Regards
> >
> >
> > Masahiro Yamada

[PATCH 02/12] kbuild: add header_install dependency to scripts

[Daniel Gomez via B4 Relay]

From: Daniel Gomez <da.gomez@samsung.com>

Export kernel headers necessary for the tools located in scripts/. This
ensures kernel headers are generated before building scripts/selinux.

Kernel headers required for building are: asm/types.h, asm/bitsperlong.h
and asm/poix_types.h.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 44c02a6f60a1..7ac079955a94 100644
--- a/Makefile
+++ b/Makefile
@@ -1173,7 +1173,7 @@ include/config/kernel.release: FORCE
 # Carefully list dependencies so we do not try to build scripts twice
 # in parallel
 PHONY += scripts
-scripts: scripts_basic scripts_dtc
+scripts: headers_install scripts_basic scripts_dtc
 	$(Q)$(MAKE) $(build)=$(@)
 
 # Things we need to do before we recursively start building the kernel

-- 
Git-146)

Re: [PATCH 02/12] kbuild: add header_install dependency to scripts

[Nicolas Schier]

On Wed, Aug 07, 2024 at 01:09:16AM +0200, Daniel Gomez via B4 Relay wrote:
> From: Daniel Gomez <da.gomez@samsung.com>
> 
> Export kernel headers necessary for the tools located in scripts/. This
> ensures kernel headers are generated before building scripts/selinux.
> 
> Kernel headers required for building are: asm/types.h, asm/bitsperlong.h
> and asm/poix_types.h.
> 
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 44c02a6f60a1..7ac079955a94 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1173,7 +1173,7 @@ include/config/kernel.release: FORCE
>  # Carefully list dependencies so we do not try to build scripts twice
>  # in parallel
>  PHONY += scripts
> -scripts: scripts_basic scripts_dtc
> +scripts: headers_install scripts_basic scripts_dtc
>  	$(Q)$(MAKE) $(build)=$(@)

Since commit 59b2bd05f5f4 ("kbuild: add 'headers' target to build up
uapi headers in usr/include", 2019-06-04), composing the user-space
header tree is separated from the actual installation to
$(INSTALL_HDR_PATH)/include.  Thus, you do not want to depend in
'headers_install' but on 'headers' instead.

Nevertheless, I am suspecting that this leads to trouble.  E.g.: if
scripts/* include $(objtree)/usr/include/asm/*.h this will probably
break cross-arch-building.

Kind regards,
Nicolas

[PATCH 03/12] file2alias: fix uuid_t definitions for macos

[Daniel Gomez via B4 Relay]

From: Daniel Gomez <da.gomez@samsung.com>

The uuid_t struct defined in sys/types.h on macOS hosts conflicts with
the one defined in file2alias, resulting in the typedef redefinition
error below. To resolve this conflict, redefine the uuid_t specifically
for macOS hosts.

Error:
  HOSTCC  scripts/mod/file2alias.o scripts/mod/file2alias.c:45:3:
error: typedef redefinition with different types ('struct uuid_t' vs
'__darwin_uuid_t' (aka 'unsigned char[16]'))    45 | } uuid_t;       |
^
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   sys/_types/_uuid_t.h:31:25: note: previous definition is here 31 |
   typedef __darwin_uuid_t uuid_t;    |                         ^
scripts/mod/file2alias.c:1354:7: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1354 |
 uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1354:19: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1354 |
 uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1354:31: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1354 |
 uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1354:43: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1354 |
 uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1354:55: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1354 |
 uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1355:7: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1355 |
 uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1355:19: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1355 |
 uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1355:31: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1355 |
 uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1355:43: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1355 |
 uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1355:55: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1355 |
 uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1356:7: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1356 |
 uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1356:20: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1356 |
 uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1356:33: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1356 |
 uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1356:46: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1356 |
 uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1356:59: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1356 |
 uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
scripts/mod/file2alias.c:1357:7: error: member reference base
 type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
 'unsigned char[16]') is not a structure or union 1357 |
 uuid->b[15]);      |                 ~~~~^ ~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
   secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
   __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
   |                                                        ^~~~~~~~~~~
17 errors generated.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 scripts/mod/file2alias.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 99dce93a4188..ab743f6d60ef 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -11,6 +11,9 @@
  */
 
 #include "modpost.h"
+#ifdef __APPLE__
+#define uuid_t sys_uuid_t
+#endif
 #include "devicetable-offsets.h"
 
 /* We use the ELF typedefs for kernel_ulong_t but bite the bullet and

-- 
Git-146)

Re: [PATCH 03/12] file2alias: fix uuid_t definitions for macos

[Nicolas Schier]

On Wed, Aug 07, 2024 at 01:09:17AM +0200, Daniel Gomez via B4 Relay wrote:
> From: Daniel Gomez <da.gomez@samsung.com>
> 
> The uuid_t struct defined in sys/types.h on macOS hosts conflicts with
> the one defined in file2alias, resulting in the typedef redefinition
> error below. To resolve this conflict, redefine the uuid_t specifically
> for macOS hosts.
> 
> Error:
>   HOSTCC  scripts/mod/file2alias.o scripts/mod/file2alias.c:45:3:
> error: typedef redefinition with different types ('struct uuid_t' vs
> '__darwin_uuid_t' (aka 'unsigned char[16]'))    45 | } uuid_t;       |
> ^
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    sys/_types/_uuid_t.h:31:25: note: previous definition is here 31 |
>    typedef __darwin_uuid_t uuid_t;    |                         ^
> scripts/mod/file2alias.c:1354:7: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1354 |
>  uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1354:19: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1354 |
>  uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1354:31: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1354 |
>  uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1354:43: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1354 |
>  uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1354:55: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1354 |
>  uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1355:7: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1355 |
>  uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1355:19: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1355 |
>  uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1355:31: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1355 |
>  uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1355:43: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1355 |
>  uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1355:55: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1355 |
>  uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1356:7: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1356 |
>  uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1356:20: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1356 |
>  uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1356:33: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1356 |
>  uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1356:46: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1356 |
>  uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1356:59: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1356 |
>  uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
>  ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> scripts/mod/file2alias.c:1357:7: error: member reference base
>  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
>  'unsigned char[16]') is not a structure or union 1357 |
>  uuid->b[15]);      |                 ~~~~^ ~
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
>    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
>    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
>    |                                                        ^~~~~~~~~~~
> 17 errors generated.
> 
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
>  scripts/mod/file2alias.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> index 99dce93a4188..ab743f6d60ef 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -11,6 +11,9 @@
>   */
>  
>  #include "modpost.h"
> +#ifdef __APPLE__
> +#define uuid_t sys_uuid_t
> +#endif
>  #include "devicetable-offsets.h"
>  
>  /* We use the ELF typedefs for kernel_ulong_t but bite the bullet and
> 

Have you tried to incorporate something like

  HOST_EXTRACFLAGS_file2alias.o += -D_UUID_T -D__GETHOSTUUID_H

for MacOS-based builds into scripts/mod/Makefile (cp. [1])?

I think it would be nice to keep cross-os build dependencies in
Makefiles as far as possible.

Kind regards,
Nicolas


[1]: https://kloenk.eu/posts/build-linux-on-m1-macos/

Re: [PATCH 03/12] file2alias: fix uuid_t definitions for macos

[Daniel Gomez]

On Wed, Aug 07, 2024 at 05:30:40PM GMT, Nicolas Schier wrote:
> On Wed, Aug 07, 2024 at 01:09:17AM +0200, Daniel Gomez via B4 Relay wrote:
> > From: Daniel Gomez <da.gomez@samsung.com>
> > 
> > The uuid_t struct defined in sys/types.h on macOS hosts conflicts with
> > the one defined in file2alias, resulting in the typedef redefinition
> > error below. To resolve this conflict, redefine the uuid_t specifically
> > for macOS hosts.
> > 
> > Error:
> >   HOSTCC  scripts/mod/file2alias.o scripts/mod/file2alias.c:45:3:
> > error: typedef redefinition with different types ('struct uuid_t' vs
> > '__darwin_uuid_t' (aka 'unsigned char[16]'))    45 | } uuid_t;       |
> > ^
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    sys/_types/_uuid_t.h:31:25: note: previous definition is here 31 |
> >    typedef __darwin_uuid_t uuid_t;    |                         ^
> > scripts/mod/file2alias.c:1354:7: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1354 |
> >  uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1354:19: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1354 |
> >  uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1354:31: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1354 |
> >  uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1354:43: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1354 |
> >  uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1354:55: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1354 |
> >  uuid->b[0], uuid->b[1], uuid->b[2], uuid->b[3], uuid->b[4],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1355:7: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1355 |
> >  uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1355:19: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1355 |
> >  uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1355:31: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1355 |
> >  uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1355:43: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1355 |
> >  uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1355:55: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1355 |
> >  uuid->b[5], uuid->b[6], uuid->b[7], uuid->b[8], uuid->b[9],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1356:7: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1356 |
> >  uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1356:20: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1356 |
> >  uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1356:33: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1356 |
> >  uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1356:46: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1356 |
> >  uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1356:59: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1356 |
> >  uuid->b[10], uuid->b[11], uuid->b[12], uuid->b[13], uuid->b[14],      |
> >  ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > scripts/mod/file2alias.c:1357:7: error: member reference base
> >  type 'typeof (((struct tee_client_device_id *)0)->uuid)' (aka
> >  'unsigned char[16]') is not a structure or union 1357 |
> >  uuid->b[15]);      |                 ~~~~^ ~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/
> >    secure/_stdio.h:47:56: note: expanded from macro 'sprintf' 47 |
> >    __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> >    |                                                        ^~~~~~~~~~~
> > 17 errors generated.
> > 
> > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > ---
> >  scripts/mod/file2alias.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> > index 99dce93a4188..ab743f6d60ef 100644
> > --- a/scripts/mod/file2alias.c
> > +++ b/scripts/mod/file2alias.c
> > @@ -11,6 +11,9 @@
> >   */
> >  
> >  #include "modpost.h"
> > +#ifdef __APPLE__
> > +#define uuid_t sys_uuid_t
> > +#endif
> >  #include "devicetable-offsets.h"
> >  
> >  /* We use the ELF typedefs for kernel_ulong_t but bite the bullet and
> > 
> 
> Have you tried to incorporate something like
> 
>   HOST_EXTRACFLAGS_file2alias.o += -D_UUID_T -D__GETHOSTUUID_H

Thank you for the suggestion. It worked after including the following line in
the Makefile:

HOSTCFLAGS_file2alias.o += -D_UUID_T -D__GETHOSTUUID_H

> 
> for MacOS-based builds into scripts/mod/Makefile (cp. [1])?
> 
> I think it would be nice to keep cross-os build dependencies in
> Makefiles as far as possible.
> 
> Kind regards,
> Nicolas
> 
> 
> [1]: https://protect2.fireeye.com/v1/url?k=74c95bb1-15424ea8-74c8d0fe-74fe485cbfec-af6e3e40b0032f68&q=1&e=42c5b47d-7d52-4aa1-8a1e-9dbc36fa1953&u=https%3A%2F%2Fkloenk.eu%2Fposts%2Fbuild-linux-on-m1-macos%2F

[PATCH 04/12] drm/xe: xe_gen_wa_oob: fix program_invocation_short_name for macos

[Daniel Gomez via B4 Relay]

From: Daniel Gomez <da.gomez@samsung.com>

Use getprogname() [1] instead of program_invocation_short_name() [2]
for macOS hosts.

[1]:
https://www.gnu.org/software/gnulib/manual/html_node/
program_005finvocation_005fshort_005fname.html

[2]:
https://developer.apple.com/library/archive/documentation/System/
Conceptual/ManPages_iPhoneOS/man3/getprogname.3.html

Fixes build error for macOS hosts:

drivers/gpu/drm/xe/xe_gen_wa_oob.c:34:3: error: use of
undeclared identifier 'program_invocation_short_name'    34 |
program_invocation_short_name);       |                 ^ 1 error
generated.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 drivers/gpu/drm/xe/xe_gen_wa_oob.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_gen_wa_oob.c b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
index 904cf47925aa..079b8870c461 100644
--- a/drivers/gpu/drm/xe/xe_gen_wa_oob.c
+++ b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
@@ -9,6 +9,12 @@
 #include <stdbool.h>
 #include <stdio.h>
 #include <string.h>
+#define PROG_INV_NAME program_invocation_short_name
+
+#ifdef __APPLE__
+#include <stdlib.h>
+#define PROG_INV_NAME getprogname()
+#endif
 
 #define HEADER \
 	"// SPDX-License-Identifier: MIT\n" \
@@ -31,7 +37,7 @@
 static void print_usage(FILE *f)
 {
 	fprintf(f, "usage: %s <input-rule-file> <generated-c-source-file> <generated-c-header-file>\n",
-		program_invocation_short_name);
+		PROG_INV_NAME);
 }
 
 static void print_parse_error(const char *err_msg, const char *line,

-- 
Git-146)

Re: [PATCH 04/12] drm/xe: xe_gen_wa_oob: fix program_invocation_short_name for macos

[Lucas De Marchi]

On Wed, Aug 07, 2024 at 01:09:18AM GMT, Daniel Gomez via B4 Relay wrote:
>From: Daniel Gomez <da.gomez@samsung.com>
>
>Use getprogname() [1] instead of program_invocation_short_name() [2]
>for macOS hosts.
>
>[1]:
>https://www.gnu.org/software/gnulib/manual/html_node/
>program_005finvocation_005fshort_005fname.html
>
>[2]:
>https://developer.apple.com/library/archive/documentation/System/
>Conceptual/ManPages_iPhoneOS/man3/getprogname.3.html
>
>Fixes build error for macOS hosts:
>
>drivers/gpu/drm/xe/xe_gen_wa_oob.c:34:3: error: use of
>undeclared identifier 'program_invocation_short_name'    34 |
>program_invocation_short_name);       |                 ^ 1 error
>generated.
>
>Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
>---
> drivers/gpu/drm/xe/xe_gen_wa_oob.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/xe/xe_gen_wa_oob.c b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
>index 904cf47925aa..079b8870c461 100644
>--- a/drivers/gpu/drm/xe/xe_gen_wa_oob.c
>+++ b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
>@@ -9,6 +9,12 @@
> #include <stdbool.h>
> #include <stdio.h>
> #include <string.h>
>+#define PROG_INV_NAME program_invocation_short_name
>+
>+#ifdef __APPLE__
>+#include <stdlib.h>
>+#define PROG_INV_NAME getprogname()
>+#endif
>
> #define HEADER \
> 	"// SPDX-License-Identifier: MIT\n" \
>@@ -31,7 +37,7 @@
> static void print_usage(FILE *f)
> {
> 	fprintf(f, "usage: %s <input-rule-file> <generated-c-source-file> <generated-c-header-file>\n",
>-		program_invocation_short_name);
>+		PROG_INV_NAME);

instead of doing that, can we a) include stdlib.h unconditionally and b)
add here a
`static const char *program_invocation_short_name = getprogname()` so we
don't need to change the common case and just handle the "build on
macos" as a compat layer?

Lucas De Marchi

> }
>
> static void print_parse_error(const char *err_msg, const char *line,
>
>-- 
>Git-146)
>
>

Re: [PATCH 04/12] drm/xe: xe_gen_wa_oob: fix program_invocation_short_name for macos

[Daniel Gomez]

On Tue, Aug 06, 2024 at 08:50:09PM GMT, Lucas De Marchi wrote:
> On Wed, Aug 07, 2024 at 01:09:18AM GMT, Daniel Gomez via B4 Relay wrote:
> > From: Daniel Gomez <da.gomez@samsung.com>
> > 
> > Use getprogname() [1] instead of program_invocation_short_name() [2]
> > for macOS hosts.
> > 
> > [1]:
> > https://www.gnu.org/software/gnulib/manual/html_node/
> > program_005finvocation_005fshort_005fname.html
> > 
> > [2]:
> > https://developer.apple.com/library/archive/documentation/System/
> > Conceptual/ManPages_iPhoneOS/man3/getprogname.3.html
> > 
> > Fixes build error for macOS hosts:
> > 
> > drivers/gpu/drm/xe/xe_gen_wa_oob.c:34:3: error: use of
> > undeclared identifier 'program_invocation_short_name'    34 |
> > program_invocation_short_name);       |                 ^ 1 error
> > generated.
> > 
> > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > ---
> > drivers/gpu/drm/xe/xe_gen_wa_oob.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_gen_wa_oob.c b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
> > index 904cf47925aa..079b8870c461 100644
> > --- a/drivers/gpu/drm/xe/xe_gen_wa_oob.c
> > +++ b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
> > @@ -9,6 +9,12 @@
> > #include <stdbool.h>
> > #include <stdio.h>
> > #include <string.h>
> > +#define PROG_INV_NAME program_invocation_short_name
> > +
> > +#ifdef __APPLE__
> > +#include <stdlib.h>
> > +#define PROG_INV_NAME getprogname()
> > +#endif
> > 
> > #define HEADER \
> > 	"// SPDX-License-Identifier: MIT\n" \
> > @@ -31,7 +37,7 @@
> > static void print_usage(FILE *f)
> > {
> > 	fprintf(f, "usage: %s <input-rule-file> <generated-c-source-file> <generated-c-header-file>\n",
> > -		program_invocation_short_name);
> > +		PROG_INV_NAME);
> 
> instead of doing that, can we a) include stdlib.h unconditionally and b)
> add here a
> `static const char *program_invocation_short_name = getprogname()` so we
> don't need to change the common case and just handle the "build on
> macos" as a compat layer?

Does this align with your suggestion (v1 diff)?

Note that static cannot be use here.

diff --git a/drivers/gpu/drm/xe/xe_gen_wa_oob.c b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
index 079b8870c461..b3add20ccb01 100644
--- a/drivers/gpu/drm/xe/xe_gen_wa_oob.c
+++ b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
@@ -9,12 +9,7 @@
 #include <stdbool.h>
 #include <stdio.h>
 #include <string.h>
-#define PROG_INV_NAME program_invocation_short_name
-
-#ifdef __APPLE__
 #include <stdlib.h>
-#define PROG_INV_NAME getprogname()
-#endif

 #define HEADER \
        "// SPDX-License-Identifier: MIT\n" \
@@ -36,8 +31,11 @@

 static void print_usage(FILE *f)
 {
+#ifdef __APPLE__
+       const char *program_invocation_short_name = getprogname();
+#endif
        fprintf(f, "usage: %s <input-rule-file> <generated-c-source-file> <generated-c-header-file>\n",
-               PROG_INV_NAME);
+               program_invocation_short_name);
 }

 static void print_parse_error(const char *err_msg, const char *line,

> 
> Lucas De Marchi
> 
> > }
> > 
> > static void print_parse_error(const char *err_msg, const char *line,
> > 
> > -- 
> > Git-146)
> > 
> > 

Re: [PATCH 04/12] drm/xe: xe_gen_wa_oob: fix program_invocation_short_name for macos

[Lucas De Marchi]

On Wed, Aug 07, 2024 at 08:13:51AM GMT, Daniel Gomez wrote:
>On Tue, Aug 06, 2024 at 08:50:09PM GMT, Lucas De Marchi wrote:
>> On Wed, Aug 07, 2024 at 01:09:18AM GMT, Daniel Gomez via B4 Relay wrote:
>> > From: Daniel Gomez <da.gomez@samsung.com>
>> >
>> > Use getprogname() [1] instead of program_invocation_short_name() [2]
>> > for macOS hosts.
>> >
>> > [1]:
>> > https://www.gnu.org/software/gnulib/manual/html_node/
>> > program_005finvocation_005fshort_005fname.html
>> >
>> > [2]:
>> > https://developer.apple.com/library/archive/documentation/System/
>> > Conceptual/ManPages_iPhoneOS/man3/getprogname.3.html
>> >
>> > Fixes build error for macOS hosts:
>> >
>> > drivers/gpu/drm/xe/xe_gen_wa_oob.c:34:3: error: use of
>> > undeclared identifier 'program_invocation_short_name'    34 |
>> > program_invocation_short_name);       |                 ^ 1 error
>> > generated.
>> >
>> > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
>> > ---
>> > drivers/gpu/drm/xe/xe_gen_wa_oob.c | 8 +++++++-
>> > 1 file changed, 7 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/xe/xe_gen_wa_oob.c b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
>> > index 904cf47925aa..079b8870c461 100644
>> > --- a/drivers/gpu/drm/xe/xe_gen_wa_oob.c
>> > +++ b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
>> > @@ -9,6 +9,12 @@
>> > #include <stdbool.h>
>> > #include <stdio.h>
>> > #include <string.h>
>> > +#define PROG_INV_NAME program_invocation_short_name
>> > +
>> > +#ifdef __APPLE__
>> > +#include <stdlib.h>
>> > +#define PROG_INV_NAME getprogname()
>> > +#endif
>> >
>> > #define HEADER \
>> > 	"// SPDX-License-Identifier: MIT\n" \
>> > @@ -31,7 +37,7 @@
>> > static void print_usage(FILE *f)
>> > {
>> > 	fprintf(f, "usage: %s <input-rule-file> <generated-c-source-file> <generated-c-header-file>\n",
>> > -		program_invocation_short_name);
>> > +		PROG_INV_NAME);
>>
>> instead of doing that, can we a) include stdlib.h unconditionally and b)
>> add here a
>> `static const char *program_invocation_short_name = getprogname()` so we
>> don't need to change the common case and just handle the "build on
>> macos" as a compat layer?
>
>Does this align with your suggestion (v1 diff)?

yes, just a nit that in xe we keep the includes sorted alphabetically,
so the stdlib.h include should move up one line. Other than that,

// Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>

... assuming the rest of the series and idea about building the kernel
on macOS is not pushed back.

Lucas De Marchi


>
>Note that static cannot be use here.
>
>diff --git a/drivers/gpu/drm/xe/xe_gen_wa_oob.c b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
>index 079b8870c461..b3add20ccb01 100644
>--- a/drivers/gpu/drm/xe/xe_gen_wa_oob.c
>+++ b/drivers/gpu/drm/xe/xe_gen_wa_oob.c
>@@ -9,12 +9,7 @@
> #include <stdbool.h>
> #include <stdio.h>
> #include <string.h>
>-#define PROG_INV_NAME program_invocation_short_name
>-
>-#ifdef __APPLE__
> #include <stdlib.h>
>-#define PROG_INV_NAME getprogname()
>-#endif
>
> #define HEADER \
>        "// SPDX-License-Identifier: MIT\n" \
>@@ -36,8 +31,11 @@
>
> static void print_usage(FILE *f)
> {
>+#ifdef __APPLE__
>+       const char *program_invocation_short_name = getprogname();
>+#endif
>        fprintf(f, "usage: %s <input-rule-file> <generated-c-source-file> <generated-c-header-file>\n",
>-               PROG_INV_NAME);
>+               program_invocation_short_name);
> }
>
> static void print_parse_error(const char *err_msg, const char *line,
>
>>
>> Lucas De Marchi
>>
>> > }
>> >
>> > static void print_parse_error(const char *err_msg, const char *line,
>> >
>> > --
>> > Git-146)
>> >
>> >

[PATCH 05/12] accessiblity/speakup: genmap and makemapdata require linux/version.h

[Daniel Gomez via B4 Relay]

From: Daniel Gomez <da.gomez@samsung.com>

Both genmap and makemapdata require the linux/version.h header. To
ensure successful builds on macOS hosts, make sure usr/include is
included in the HOSTCFLAGS.

Fixes errors:
drivers/accessibility/speakup/genmap.c:13:10: fatal error: 'linux/version.h' file not found
   13 | #include <linux/version.h>
      |          ^~~~~~~~~~~~~~~~~
1 error generated.

drivers/accessibility/speakup/makemapdata.c:13:10: fatal error: 'linux/version.h' file not found
   13 | #include <linux/version.h>
      |          ^~~~~~~~~~~~~~~~~
1 error generated.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 drivers/accessibility/speakup/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/accessibility/speakup/Makefile b/drivers/accessibility/speakup/Makefile
index 6f6a83565c0d..74ee0c31370f 100644
--- a/drivers/accessibility/speakup/Makefile
+++ b/drivers/accessibility/speakup/Makefile
@@ -38,6 +38,7 @@ clean-files := mapdata.h speakupmap.h
 # Generate mapdata.h from headers
 hostprogs += makemapdata
 makemapdata-objs := makemapdata.o
+HOSTCFLAGS_makemapdata.o += -I$(srctree)/usr/include
 
 quiet_cmd_mkmap = MKMAP   $@
       cmd_mkmap = TOPDIR=$(srctree) \
@@ -51,6 +52,7 @@ $(obj)/mapdata.h: $(obj)/makemapdata
 # Generate speakupmap.h from mapdata.h
 hostprogs += genmap
 genmap-objs := genmap.o
+HOSTCFLAGS_genmap.o += -I$(srctree)/usr/include
 $(obj)/genmap.o: $(obj)/mapdata.h
 
 quiet_cmd_genmap = GENMAP  $@

-- 
Git-146)

Re: [PATCH 05/12] accessiblity/speakup: genmap and makemapdata require linux/version.h

[Masahiro Yamada]

genmap and makemapdata DO NOT require linux/version.h


Removing bogus "#include <linux/version.h>" is the right fix.






On Wed, Aug 7, 2024 at 8:10 AM Daniel Gomez via B4 Relay
<devnull+da.gomez.samsung.com@kernel.org> wrote:
>
> From: Daniel Gomez <da.gomez@samsung.com>
>
> Both genmap and makemapdata require the linux/version.h header. To
> ensure successful builds on macOS hosts, make sure usr/include is
> included in the HOSTCFLAGS.
>
> Fixes errors:
> drivers/accessibility/speakup/genmap.c:13:10: fatal error: 'linux/version.h' file not found
>    13 | #include <linux/version.h>
>       |          ^~~~~~~~~~~~~~~~~
> 1 error generated.
>
> drivers/accessibility/speakup/makemapdata.c:13:10: fatal error: 'linux/version.h' file not found
>    13 | #include <linux/version.h>
>       |          ^~~~~~~~~~~~~~~~~
> 1 error generated.
>
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
>  drivers/accessibility/speakup/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/accessibility/speakup/Makefile b/drivers/accessibility/speakup/Makefile
> index 6f6a83565c0d..74ee0c31370f 100644
> --- a/drivers/accessibility/speakup/Makefile
> +++ b/drivers/accessibility/speakup/Makefile
> @@ -38,6 +38,7 @@ clean-files := mapdata.h speakupmap.h
>  # Generate mapdata.h from headers
>  hostprogs += makemapdata
>  makemapdata-objs := makemapdata.o
> +HOSTCFLAGS_makemapdata.o += -I$(srctree)/usr/include
>
>  quiet_cmd_mkmap = MKMAP   $@
>        cmd_mkmap = TOPDIR=$(srctree) \
> @@ -51,6 +52,7 @@ $(obj)/mapdata.h: $(obj)/makemapdata
>  # Generate speakupmap.h from mapdata.h
>  hostprogs += genmap
>  genmap-objs := genmap.o
> +HOSTCFLAGS_genmap.o += -I$(srctree)/usr/include
>  $(obj)/genmap.o: $(obj)/mapdata.h
>
>  quiet_cmd_genmap = GENMAP  $@
>
> --
> Git-146)
>
>


--
Best Regards
Masahiro Yamada

[PATCH 06/12] selinux/genheaders: include bitsperlong and posix_types headers

[Daniel Gomez via B4 Relay]

From: Daniel Gomez <da.gomez@samsung.com>

The genheaders requires the bitsperlong.h and posix_types.h headers.
To ensure these headers are found during compilation on macOS hosts,
add usr/include to HOST_EXTRACFLAGS in the genheaders Makefile. This
adjustment allows the compiler to locate all necessary headers when they
are not available by default on macOS.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 scripts/selinux/genheaders/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/selinux/genheaders/Makefile b/scripts/selinux/genheaders/Makefile
index 1faf7f07e8db..017149c90f8e 100644
--- a/scripts/selinux/genheaders/Makefile
+++ b/scripts/selinux/genheaders/Makefile
@@ -2,4 +2,5 @@
 hostprogs-always-y += genheaders
 HOST_EXTRACFLAGS += \
 	-I$(srctree)/include/uapi -I$(srctree)/include \
-	-I$(srctree)/security/selinux/include
+	-I$(srctree)/security/selinux/include \
+	-I$(srctree)/usr/include

-- 
Git-146)

Re: [PATCH 06/12] selinux/genheaders: include bitsperlong and posix_types headers

[Paul Moore]

On Tue, Aug 6, 2024 at 7:10 PM Daniel Gomez via B4 Relay
<devnull+da.gomez.samsung.com@kernel.org> wrote:
>
> From: Daniel Gomez <da.gomez@samsung.com>
>
> The genheaders requires the bitsperlong.h and posix_types.h headers.
> To ensure these headers are found during compilation on macOS hosts,
> add usr/include to HOST_EXTRACFLAGS in the genheaders Makefile. This
> adjustment allows the compiler to locate all necessary headers when they
> are not available by default on macOS.
>
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
>  scripts/selinux/genheaders/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

This patch, and 7/12, look fine to me.  I can pull them into the
SELinux tree now, or would you prefer them to go via a different tree?

-- 
paul-moore.com

Re: [PATCH 06/12] selinux/genheaders: include bitsperlong and posix_types headers

[Nicolas Schier]

On Wed, Aug 07, 2024 at 01:09:20AM +0200, Daniel Gomez via B4 Relay wrote:
> From: Daniel Gomez <da.gomez@samsung.com>
> 
> The genheaders requires the bitsperlong.h and posix_types.h headers.
> To ensure these headers are found during compilation on macOS hosts,
> add usr/include to HOST_EXTRACFLAGS in the genheaders Makefile. This
> adjustment allows the compiler to locate all necessary headers when they
> are not available by default on macOS.
> 
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
>  scripts/selinux/genheaders/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/selinux/genheaders/Makefile b/scripts/selinux/genheaders/Makefile
> index 1faf7f07e8db..017149c90f8e 100644
> --- a/scripts/selinux/genheaders/Makefile
> +++ b/scripts/selinux/genheaders/Makefile
> @@ -2,4 +2,5 @@
>  hostprogs-always-y += genheaders
>  HOST_EXTRACFLAGS += \
>  	-I$(srctree)/include/uapi -I$(srctree)/include \
> -	-I$(srctree)/security/selinux/include
> +	-I$(srctree)/security/selinux/include \
> +	-I$(srctree)/usr/include

'make headers' composes the UAPI header tree in $(objtree)/usr/include.
So, if you build out-of-source, -I$(srctree)/usr/include will not match.
Just remove the '$(srctree)/' prefix as '$(objtree)/' is always '.'.

But I am suspecting that this break cross-building.

Kind regards,
Nicolas

Re: [PATCH 06/12] selinux/genheaders: include bitsperlong and posix_types headers

[Masahiro Yamada]

On Thu, Aug 8, 2024 at 12:39 AM Nicolas Schier <nicolas@fjasle.eu> wrote:
>
> On Wed, Aug 07, 2024 at 01:09:20AM +0200, Daniel Gomez via B4 Relay wrote:
> > From: Daniel Gomez <da.gomez@samsung.com>
> >
> > The genheaders requires the bitsperlong.h and posix_types.h headers.
> > To ensure these headers are found during compilation on macOS hosts,
> > add usr/include to HOST_EXTRACFLAGS in the genheaders Makefile. This
> > adjustment allows the compiler to locate all necessary headers when they
> > are not available by default on macOS.
> >
> > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > ---
> >  scripts/selinux/genheaders/Makefile | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/selinux/genheaders/Makefile b/scripts/selinux/genheaders/Makefile
> > index 1faf7f07e8db..017149c90f8e 100644
> > --- a/scripts/selinux/genheaders/Makefile
> > +++ b/scripts/selinux/genheaders/Makefile
> > @@ -2,4 +2,5 @@
> >  hostprogs-always-y += genheaders
> >  HOST_EXTRACFLAGS += \
> >       -I$(srctree)/include/uapi -I$(srctree)/include \
> > -     -I$(srctree)/security/selinux/include
> > +     -I$(srctree)/security/selinux/include \
> > +     -I$(srctree)/usr/include
>
> 'make headers' composes the UAPI header tree in $(objtree)/usr/include.
> So, if you build out-of-source, -I$(srctree)/usr/include will not match.
> Just remove the '$(srctree)/' prefix as '$(objtree)/' is always '.'.


Right.


> But I am suspecting that this break cross-building.


Right.

We cannot do this.


--
Best Regards
Masahiro Yamada

Re: [PATCH 06/12] selinux/genheaders: include bitsperlong and posix_types headers

[Paul Moore]

On Wed, Aug 7, 2024 at 11:45 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Thu, Aug 8, 2024 at 12:39 AM Nicolas Schier <nicolas@fjasle.eu> wrote:
> >
> > On Wed, Aug 07, 2024 at 01:09:20AM +0200, Daniel Gomez via B4 Relay wrote:
> > > From: Daniel Gomez <da.gomez@samsung.com>
> > >
> > > The genheaders requires the bitsperlong.h and posix_types.h headers.
> > > To ensure these headers are found during compilation on macOS hosts,
> > > add usr/include to HOST_EXTRACFLAGS in the genheaders Makefile. This
> > > adjustment allows the compiler to locate all necessary headers when they
> > > are not available by default on macOS.
> > >
> > > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > > ---
> > >  scripts/selinux/genheaders/Makefile | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/selinux/genheaders/Makefile b/scripts/selinux/genheaders/Makefile
> > > index 1faf7f07e8db..017149c90f8e 100644
> > > --- a/scripts/selinux/genheaders/Makefile
> > > +++ b/scripts/selinux/genheaders/Makefile
> > > @@ -2,4 +2,5 @@
> > >  hostprogs-always-y += genheaders
> > >  HOST_EXTRACFLAGS += \
> > >       -I$(srctree)/include/uapi -I$(srctree)/include \
> > > -     -I$(srctree)/security/selinux/include
> > > +     -I$(srctree)/security/selinux/include \
> > > +     -I$(srctree)/usr/include
> >
> > 'make headers' composes the UAPI header tree in $(objtree)/usr/include.
> > So, if you build out-of-source, -I$(srctree)/usr/include will not match.
> > Just remove the '$(srctree)/' prefix as '$(objtree)/' is always '.'.
>
> Right.
>
> > But I am suspecting that this break cross-building.
>
> Right.
>
> We cannot do this.

Thanks for the review and catching this :)

-- 
paul-moore.com

Re: [PATCH 06/12] selinux/genheaders: include bitsperlong and posix_types headers

[Daniel Gomez]

On Wed, Aug 07, 2024 at 05:38:28PM GMT, Nicolas Schier wrote:
> On Wed, Aug 07, 2024 at 01:09:20AM +0200, Daniel Gomez via B4 Relay wrote:
> > From: Daniel Gomez <da.gomez@samsung.com>
> > 
> > The genheaders requires the bitsperlong.h and posix_types.h headers.
> > To ensure these headers are found during compilation on macOS hosts,
> > add usr/include to HOST_EXTRACFLAGS in the genheaders Makefile. This
> > adjustment allows the compiler to locate all necessary headers when they
> > are not available by default on macOS.
> > 
> > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > ---
> >  scripts/selinux/genheaders/Makefile | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/selinux/genheaders/Makefile b/scripts/selinux/genheaders/Makefile
> > index 1faf7f07e8db..017149c90f8e 100644
> > --- a/scripts/selinux/genheaders/Makefile
> > +++ b/scripts/selinux/genheaders/Makefile
> > @@ -2,4 +2,5 @@
> >  hostprogs-always-y += genheaders
> >  HOST_EXTRACFLAGS += \
> >  	-I$(srctree)/include/uapi -I$(srctree)/include \
> > -	-I$(srctree)/security/selinux/include
> > +	-I$(srctree)/security/selinux/include \
> > +	-I$(srctree)/usr/include
> 
> 'make headers' composes the UAPI header tree in $(objtree)/usr/include.
> So, if you build out-of-source, -I$(srctree)/usr/include will not match.
> Just remove the '$(srctree)/' prefix as '$(objtree)/' is always '.'.

The 'headers' target also deploys installs the headers in arch/$(SRCARCH)/
include/uapi, so I've updated selinux/genheaders/Makefile to the following:

diff --git a/scripts/selinux/genheaders/Makefile b/scripts/selinux/genheaders/Makefile
index 1faf7f07e8db..ae1f195b6f67 100644
--- a/scripts/selinux/genheaders/Makefile
+++ b/scripts/selinux/genheaders/Makefile
@@ -2,4 +2,6 @@
 hostprogs-always-y += genheaders
 HOST_EXTRACFLAGS += \
        -I$(srctree)/include/uapi -I$(srctree)/include \
-       -I$(srctree)/security/selinux/include
+       -I$(srctree)/security/selinux/include \
+       -I$(objtree)/arch/$(SRCARCH)/include/generated/uapi \
+       -I$(objtree)/arch/$(SRCARCH)/include/uapi

The include path -I$(objtree)/arch/$(SRCARCH)/include/generated/uapi
enables locating the asm/types.h.

The include path -I$(objtree)/arch/$(SRCARCH)/include/uapi enables
locating the asm/bitsperlong.h and asm/posix_types.h.

> 
> But I am suspecting that this break cross-building.

I’ve tested this change on macOS with ARCH=arm64, as well as on Debian with
ARCH=arm64 and ARCH=x86_64. Is it enough to just confirm that cross-building
still works after this change?

> 
> Kind regards,
> Nicolas

Re: [PATCH 06/12] selinux/genheaders: include bitsperlong and posix_types headers

[Nicolas Schier]

[-- Attachment #1: Type: text/plain, Size: 6195 bytes --]

Am Wed, Aug 07, 2024 at 09:41:00PM +0000 schrieb Daniel Gomez:
> Date: Wed, 7 Aug 2024 21:41:00 +0000
> From: Daniel Gomez <da.gomez@samsung.com>
> To: Nicolas Schier <nicolas@fjasle.eu>
> CC: Masahiro Yamada <masahiroy@kernel.org>, Nathan Chancellor
>  <nathan@kernel.org>, Lucas De Marchi <lucas.demarchi@intel.com>, Thomas
>  Hellström <thomas.hellstrom@linux.intel.com>, Rodrigo Vivi
>  <rodrigo.vivi@intel.com>, Maarten Lankhorst
>  <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>,
>  Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>,
>  Daniel Vetter <daniel@ffwll.ch>, William Hubbs <w.d.hubbs@gmail.com>,
>  Chris Brannon <chris@the-brannons.com>, Kirk Reiser <kirk@reisers.ca>,
>  Samuel Thibault <samuel.thibault@ens-lyon.org>, Paul Moore
>  <paul@paul-moore.com>, Stephen Smalley <stephen.smalley.work@gmail.com>,
>  Ondrej Mosnacek <omosnace@redhat.com>, Catalin Marinas
>  <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Marc Zyngier
>  <maz@kernel.org>, Oliver Upton <oliver.upton@linux.dev>, James Morse
>  <james.morse@arm.com>, Suzuki K Poulose <suzuki.poulose@arm.com>, Zenghui
>  Yu <yuzenghui@huawei.com>, Greg Kroah-Hartman
>  <gregkh@linuxfoundation.org>, Jiri Slaby <jirislaby@kernel.org>, Nick
>  Desaulniers <ndesaulniers@google.com>, Bill Wendling <morbo@google.com>,
>  Justin Stitt <justinstitt@google.com>, "linux-kernel@vger.kernel.org"
>  <linux-kernel@vger.kernel.org>, "linux-kbuild@vger.kernel.org"
>  <linux-kbuild@vger.kernel.org>, "intel-xe@lists.freedesktop.org"
>  <intel-xe@lists.freedesktop.org>, "dri-devel@lists.freedesktop.org"
>  <dri-devel@lists.freedesktop.org>, "speakup@linux-speakup.org"
>  <speakup@linux-speakup.org>, "selinux@vger.kernel.org"
>  <selinux@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org"
>  <linux-arm-kernel@lists.infradead.org>, "kvmarm@lists.linux.dev"
>  <kvmarm@lists.linux.dev>, "linux-serial@vger.kernel.org"
>  <linux-serial@vger.kernel.org>, "llvm@lists.linux.dev"
>  <llvm@lists.linux.dev>, Finn Behrens <me@kloenk.dev>, "Daniel Gomez
>  (Samsung)" <d+samsung@kruces.com>, "gost.dev@samsung.com"
>  <gost.dev@samsung.com>
> Subject: Re: [PATCH 06/12] selinux/genheaders: include bitsperlong and
>  posix_types headers
> Message-ID: <sbj3c3tlafewy2n4pylbnpb4gwylpnyxovdykfy3dhk2wqmpry@ekhhe3mgqnd6>
> 
> On Wed, Aug 07, 2024 at 05:38:28PM GMT, Nicolas Schier wrote:
> > On Wed, Aug 07, 2024 at 01:09:20AM +0200, Daniel Gomez via B4 Relay wrote:
> > > From: Daniel Gomez <da.gomez@samsung.com>
> > > 
> > > The genheaders requires the bitsperlong.h and posix_types.h headers.
> > > To ensure these headers are found during compilation on macOS hosts,
> > > add usr/include to HOST_EXTRACFLAGS in the genheaders Makefile. This
> > > adjustment allows the compiler to locate all necessary headers when they
> > > are not available by default on macOS.
> > > 
> > > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > > ---
> > >  scripts/selinux/genheaders/Makefile | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/scripts/selinux/genheaders/Makefile b/scripts/selinux/genheaders/Makefile
> > > index 1faf7f07e8db..017149c90f8e 100644
> > > --- a/scripts/selinux/genheaders/Makefile
> > > +++ b/scripts/selinux/genheaders/Makefile
> > > @@ -2,4 +2,5 @@
> > >  hostprogs-always-y += genheaders
> > >  HOST_EXTRACFLAGS += \
> > >  	-I$(srctree)/include/uapi -I$(srctree)/include \
> > > -	-I$(srctree)/security/selinux/include
> > > +	-I$(srctree)/security/selinux/include \
> > > +	-I$(srctree)/usr/include
> > 
> > 'make headers' composes the UAPI header tree in $(objtree)/usr/include.
> > So, if you build out-of-source, -I$(srctree)/usr/include will not match.
> > Just remove the '$(srctree)/' prefix as '$(objtree)/' is always '.'.
> 
> The 'headers' target also deploys installs the headers in arch/$(SRCARCH)/
> include/uapi, so I've updated selinux/genheaders/Makefile to the following:
> 
> diff --git a/scripts/selinux/genheaders/Makefile b/scripts/selinux/genheaders/Makefile
> index 1faf7f07e8db..ae1f195b6f67 100644
> --- a/scripts/selinux/genheaders/Makefile
> +++ b/scripts/selinux/genheaders/Makefile
> @@ -2,4 +2,6 @@
>  hostprogs-always-y += genheaders
>  HOST_EXTRACFLAGS += \
>         -I$(srctree)/include/uapi -I$(srctree)/include \
> -       -I$(srctree)/security/selinux/include
> +       -I$(srctree)/security/selinux/include \
> +       -I$(objtree)/arch/$(SRCARCH)/include/generated/uapi \
> +       -I$(objtree)/arch/$(SRCARCH)/include/uapi

SRCARCH is not derived from the host but from $(ARCH) (cp. top-level
Makefile), thus you must not use arch/$(SRCARCH)/include/* for building
host progs as this breaks cross-building (e.g. consider build Linux for
32bit m68k on a arm64 host).

> 
> The include path -I$(objtree)/arch/$(SRCARCH)/include/generated/uapi
> enables locating the asm/types.h.
> 
> The include path -I$(objtree)/arch/$(SRCARCH)/include/uapi enables
> locating the asm/bitsperlong.h and asm/posix_types.h.
> 
> > 
> > But I am suspecting that this break cross-building.
> 
> I’ve tested this change on macOS with ARCH=arm64, as well as on Debian with
> ARCH=arm64 and ARCH=x86_64. Is it enough to just confirm that cross-building
> still works after this change?

No, it isn't.  asm/bitsperlong.h is probably similar (enough) for current
64-bit systems, but 32-bit platforms will have different versions.
Anyway, we must not use target arch/platform-specific header files for
host progs.  If we do, it will break.

You want to use arm64 specific header files for building your arm64 host
progs, as MacOS does not provide these (thus, it's a missing build
dependency).  As this is not common (yet), such a build hack should be limited
to MacOS/Darwin only to not accidentally break other platforms.  (Do you also
have MacOS/amd64 in mind?)

As written elsewhere, another approach could be to create and maintain a Linux
kernel dev kit for MacOS, that delivers (fetches, downloads, generates) all
missing header files.

Kind regards,
Nicolas


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 07/12] selinux/mdp: include bitsperlong and posix_types headers

[Daniel Gomez via B4 Relay]

From: Daniel Gomez <da.gomez@samsung.com>

The mdp object requires the bitsperlong.h and posix_types.h headers.
To ensure these headers are found during compilation on macOS hosts,
add usr/include to HOST_EXTRACFLAGS in the genheaders Makefile. This
adjustment allows the compiler to locate all necessary headers when they
are not available by default on macOS.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 scripts/selinux/mdp/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/selinux/mdp/Makefile b/scripts/selinux/mdp/Makefile
index d61058ddd15c..19ab8682ae3d 100644
--- a/scripts/selinux/mdp/Makefile
+++ b/scripts/selinux/mdp/Makefile
@@ -2,6 +2,7 @@
 hostprogs-always-y += mdp
 HOST_EXTRACFLAGS += \
 	-I$(srctree)/include/uapi -I$(srctree)/include \
-	-I$(srctree)/security/selinux/include -I$(objtree)/include
+	-I$(srctree)/security/selinux/include -I$(objtree)/include \
+	-I$(srctree)/usr/include
 
 clean-files	:= policy.* file_contexts

-- 
Git-146)

[PATCH 09/12] include: add endian.h support

[Daniel Gomez via B4 Relay]

From: Daniel Gomez <da.gomez@samsung.com>

macOS hosts do not include endian.h header required for gen-hyper
object. Add a copy of the include/endian.h from the GNU C Library
(glibc), version glib-2.40 into include/endian and a copy of bits/
uintn-identity.h into include/endian/bits and update the gen-hyper
Makefile to include the library path.

Remove the following from glibc include/endian.h:

diff --git a/include/endian/endian.h b/include/endian/endian.h
index fd20a2b1985d..f70e07f1d3c6 100644
--- a/include/endian/endian.h
+++ b/include/endian/endian.h
@@ -18,11 +18,6 @@
 #ifndef        _ENDIAN_H
 #define        _ENDIAN_H       1

-#include <features.h>
-
-/* Get the definitions of __*_ENDIAN, __BYTE_ORDER, and __FLOAT_WORD_ORDER.  */
-#include <bits/endian.h>
-
 #ifdef __USE_MISC
 # define LITTLE_ENDIAN __LITTLE_ENDIAN
 # define BIG_ENDIAN    __BIG_ENDIAN
@@ -30,9 +25,6 @@
 # define BYTE_ORDER    __BYTE_ORDER
 #endif

-#if defined __USE_MISC && !defined __ASSEMBLER__
-/* Conversion interfaces.  */
-# include <bits/byteswap.h>
 # include <bits/uintn-identity.h>

 # if __BYTE_ORDER == __LITTLE_ENDIAN
@@ -67,6 +59,5 @@
 #  define be64toh(x) __uint64_identity (x)
 #  define le64toh(x) __bswap_64 (x)
 # endif
-#endif

 #endif /* endian.h */

Remove the following from glibc bits/uintn-identity.h:

diff --git a/include/endian/bits/uintn-identity.h b/include/endian/bits/uintn-identity.h
index 8104070583c7..0310c9d955da 100644
--- a/include/endian/bits/uintn-identity.h
+++ b/include/endian/bits/uintn-identity.h
@@ -23,8 +23,6 @@
 #ifndef _BITS_UINTN_IDENTITY_H
 #define _BITS_UINTN_IDENTITY_H 1

-#include <bits/types.h>
-
 /* These inline functions are to ensure the appropriate type
    conversions and associated diagnostics from macros that convert to
    a given endianness.  */

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 arch/arm64/kvm/hyp/nvhe/Makefile     |  2 +-
 include/endian/bits/uintn-identity.h | 48 +++++++++++++++++++++++++++
 include/endian/endian.h              | 63 ++++++++++++++++++++++++++++++++++++
 3 files changed, 112 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index 40541c0812bf..1bbe2c2a4aed 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -15,7 +15,7 @@ ccflags-y += -fno-stack-protector	\
 	     $(DISABLE_STACKLEAK_PLUGIN)
 
 hostprogs := gen-hyprel
-HOST_EXTRACFLAGS += -I$(objtree)/include -I$(srctree)/include/elf
+HOST_EXTRACFLAGS += -I$(objtree)/include -I$(srctree)/include/elf -I$(srctree)/include/endian
 
 lib-objs := clear_page.o copy_page.o memcpy.o memset.o
 lib-objs := $(addprefix ../../../lib/, $(lib-objs))
diff --git a/include/endian/bits/uintn-identity.h b/include/endian/bits/uintn-identity.h
new file mode 100644
index 000000000000..0310c9d955da
--- /dev/null
+++ b/include/endian/bits/uintn-identity.h
@@ -0,0 +1,48 @@
+/* Inline functions to return unsigned integer values unchanged.
+   Copyright (C) 2017-2024 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <https://www.gnu.org/licenses/>.  */
+
+#if !defined _NETINET_IN_H && !defined _ENDIAN_H
+# error "Never use <bits/uintn-identity.h> directly; include <netinet/in.h> or <endian.h> instead."
+#endif
+
+#ifndef _BITS_UINTN_IDENTITY_H
+#define _BITS_UINTN_IDENTITY_H 1
+
+/* These inline functions are to ensure the appropriate type
+   conversions and associated diagnostics from macros that convert to
+   a given endianness.  */
+
+static __inline __uint16_t
+__uint16_identity (__uint16_t __x)
+{
+  return __x;
+}
+
+static __inline __uint32_t
+__uint32_identity (__uint32_t __x)
+{
+  return __x;
+}
+
+static __inline __uint64_t
+__uint64_identity (__uint64_t __x)
+{
+  return __x;
+}
+
+#endif /* _BITS_UINTN_IDENTITY_H.  */
diff --git a/include/endian/endian.h b/include/endian/endian.h
new file mode 100644
index 000000000000..f70e07f1d3c6
--- /dev/null
+++ b/include/endian/endian.h
@@ -0,0 +1,63 @@
+/* Copyright (C) 1992-2024 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <https://www.gnu.org/licenses/>.  */
+
+#ifndef	_ENDIAN_H
+#define	_ENDIAN_H	1
+
+#ifdef __USE_MISC
+# define LITTLE_ENDIAN	__LITTLE_ENDIAN
+# define BIG_ENDIAN	__BIG_ENDIAN
+# define PDP_ENDIAN	__PDP_ENDIAN
+# define BYTE_ORDER	__BYTE_ORDER
+#endif
+
+# include <bits/uintn-identity.h>
+
+# if __BYTE_ORDER == __LITTLE_ENDIAN
+#  define htobe16(x) __bswap_16 (x)
+#  define htole16(x) __uint16_identity (x)
+#  define be16toh(x) __bswap_16 (x)
+#  define le16toh(x) __uint16_identity (x)
+
+#  define htobe32(x) __bswap_32 (x)
+#  define htole32(x) __uint32_identity (x)
+#  define be32toh(x) __bswap_32 (x)
+#  define le32toh(x) __uint32_identity (x)
+
+#  define htobe64(x) __bswap_64 (x)
+#  define htole64(x) __uint64_identity (x)
+#  define be64toh(x) __bswap_64 (x)
+#  define le64toh(x) __uint64_identity (x)
+
+# else
+#  define htobe16(x) __uint16_identity (x)
+#  define htole16(x) __bswap_16 (x)
+#  define be16toh(x) __uint16_identity (x)
+#  define le16toh(x) __bswap_16 (x)
+
+#  define htobe32(x) __uint32_identity (x)
+#  define htole32(x) __bswap_32 (x)
+#  define be32toh(x) __uint32_identity (x)
+#  define le32toh(x) __bswap_32 (x)
+
+#  define htobe64(x) __uint64_identity (x)
+#  define htole64(x) __bswap_64 (x)
+#  define be64toh(x) __uint64_identity (x)
+#  define le64toh(x) __bswap_64 (x)
+# endif
+
+#endif	/* endian.h */

-- 
Git-146)

[PATCH 10/12] scripts/mod: add byteswap support

[Daniel Gomez via B4 Relay]

From: Daniel Gomez <da.gomez@samsung.com>

macOS hosts do not include byteswap.h header required for modpost
objects. Add a copy of the string/byteswap.h from the GNU C Library
(glibc), version glibc-2.40 into include/byteswap and update the modpost
Makefile to include the library.

Remove the following headers from glibc:

diff --git a/include/byteswap/byteswap.h b/include/byteswap/byteswap.h
index 66efb8fc4327..d27dd5e4bc6a 100644
--- a/include/byteswap/byteswap.h
+++ b/include/byteswap/byteswap.h
@@ -19,11 +19,6 @@
 #ifndef _BYTESWAP_H
 #define _BYTESWAP_H    1

-#include <features.h>
-
-/* Get the machine specific, optimized definitions.  */
-#include <bits/byteswap.h>
-

 /* The following definitions must all be macros, otherwise some
    of the possible optimizations are not possible.  */

Fixes build error for macOS:

$SUBARCH is [arm64]
  HOSTCC  scripts/mod/modpost.o
  HOSTCC  scripts/mod/sumversion.o
  HOSTCC  scripts/mod/symsearch.o
  HOSTCC  scripts/mod/file2alias.o
In file included from scripts/mod/symsearch.c:8:
scripts/mod/modpost.h:2:10: fatal error: 'byteswap.h' file not found
         ^~~~~~~~~~~~
In file included from scripts/mod/sumversion.c:11:
scripts/mod/modpost.h:2:10: fatal error: 'byteswap.h' file not found
         ^~~~~~~~~~~~
In file included from scripts/mod/modpost.c:23:
scripts/mod/modpost.h:2:10: fatal error: 'byteswap.h' file not found
         ^~~~~~~~~~~~
1 error generated.
make[1]: *** [scripts/Makefile.host:133: scripts/mod/symsearch.o] Error 1
make[1]: *** Waiting for unfinished jobs....
1 error generated.
In file included from scripts/mod/file2alias.c:15:
scripts/mod/modpost.h:2:10: fatal error: 'byteswap.h' file not found
         ^~~~~~~~~~~~
make[1]: *** [scripts/Makefile.host:133: scripts/mod/sumversion.o] Error 1
1 error generated.
make[1]: *** [scripts/Makefile.host:133: scripts/mod/modpost.o] Error 1
1 error generated.
make[1]: *** [scripts/Makefile.host:133: scripts/mod/file2alias.o] Error 1
make: *** [Makefile:1191: prepare0] Error 2
error: Recipe `kernel-build` failed with exit code 2

Fixes: bd78c9d71420 ("modpost: define TO_NATIVE() using bswap_*
functions") build error for macOS.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 include/byteswap/byteswap.h | 35 +++++++++++++++++++++++++++++++++++
 scripts/mod/Makefile        |  8 ++++----
 2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/include/byteswap/byteswap.h b/include/byteswap/byteswap.h
new file mode 100644
index 000000000000..d27dd5e4bc6a
--- /dev/null
+++ b/include/byteswap/byteswap.h
@@ -0,0 +1,35 @@
+/* Swap byte order for 16, 32 and 64 bit values
+   Copyright (C) 1997-2024 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <https://www.gnu.org/licenses/>.  */
+
+#ifndef _BYTESWAP_H
+#define _BYTESWAP_H	1
+
+
+/* The following definitions must all be macros, otherwise some
+   of the possible optimizations are not possible.  */
+
+/* Return a value with both bytes in the 16 bit argument swapped.  */
+#define bswap_16(x) __bswap_16 (x)
+
+/* Return a value with all bytes in the 32 bit argument swapped.  */
+#define bswap_32(x) __bswap_32 (x)
+
+/* Return a value with all bytes in the 64 bit argument swapped.  */
+#define bswap_64(x) __bswap_64 (x)
+
+#endif /* byteswap.h */
diff --git a/scripts/mod/Makefile b/scripts/mod/Makefile
index 98b4cd8cc7e6..f398dcddef58 100644
--- a/scripts/mod/Makefile
+++ b/scripts/mod/Makefile
@@ -8,10 +8,10 @@ modpost-objs	:= modpost.o file2alias.o sumversion.o symsearch.o
 
 devicetable-offsets-file := devicetable-offsets.h
 
-HOSTCFLAGS_modpost.o = -I$(srctree)/include/elf
-HOSTCFLAGS_file2alias.o = -I$(srctree)/include/elf
-HOSTCFLAGS_sumversion.o = -I$(srctree)/include/elf
-HOSTCFLAGS_symsearch.o = -I$(srctree)/include/elf
+HOSTCFLAGS_modpost.o = -I$(srctree)/include/elf -I$(srctree)/include/byteswap
+HOSTCFLAGS_file2alias.o = -I$(srctree)/include/elf -I$(srctree)/include/byteswap
+HOSTCFLAGS_sumversion.o = -I$(srctree)/include/elf -I$(srctree)/include/byteswap
+HOSTCFLAGS_symsearch.o = -I$(srctree)/include/elf -I$(srctree)/include/byteswap
 HOSTCFLAGS_mk_elfconfig.o = -I$(srctree)/include/elf
 
 $(obj)/$(devicetable-offsets-file): $(obj)/devicetable-offsets.s FORCE

-- 
Git-146)

[PATCH 11/12] tty/vt: conmakehash requires linux/limits.h

[Daniel Gomez via B4 Relay]

From: Daniel Gomez <da.gomez@samsung.com>

macOS hosts do not provide the linux/limits.h header required for
conmakehash. To address this, ensure that usr/include is included in
the conmakehash HOSTCFLAGS. This will provide the necessary header for
successful compilation on macOS.

Fixes error:
HOSTCC  drivers/tty/vt/conmakehash - due to target missing
  clang -Wp,-MMD,drivers/tty/vt/.conmakehash.d -Wall
-Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
-std=gnu11   -I ./scripts/include     -o drivers/tty/vt/conmakehash
drivers/tty/vt/conmakehash.c
drivers/tty/vt/conmakehash.c:15:10: fatal error: 'linux/
   limits.h' file not found 15 | #include <linux/limits.h>    |
   ^~~~~~~~~~~~~~~~
1 error generated.
make[5]: *** [scripts/Makefile.host:116: drivers/tty/vt/conmakehash]
Error 1
make[4]: *** [scripts/Makefile.build:485: drivers/tty/vt] Error 2
make[3]: *** [scripts/Makefile.build:485: drivers/tty] Error 2
make[2]: *** [scripts/Makefile.build:485: drivers] Error 2
make[1]: *** [/Volumes/src/kernel/linux-next/Makefile:1925: .] Error 2
make: *** [Makefile:224: __sub-make] Error 2

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 drivers/tty/vt/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/vt/Makefile b/drivers/tty/vt/Makefile
index 2c8ce8b592ed..d266895357e5 100644
--- a/drivers/tty/vt/Makefile
+++ b/drivers/tty/vt/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_CONSOLE_TRANSLATIONS)	+= consolemap.o consolemap_deftbl.o
 clean-files := consolemap_deftbl.c defkeymap.c
 
 hostprogs += conmakehash
+HOSTCFLAGS_conmakehash.o = -I$(srctree)/usr/include
 
 quiet_cmd_conmk = CONMK   $@
       cmd_conmk = $(obj)/conmakehash $< > $@

-- 
Git-146)

Re: [PATCH 11/12] tty/vt: conmakehash requires linux/limits.h

[Masahiro Yamada]

On Wed, Aug 7, 2024 at 8:10 AM Daniel Gomez via B4 Relay
<devnull+da.gomez.samsung.com@kernel.org> wrote:
>
> From: Daniel Gomez <da.gomez@samsung.com>
>
> macOS hosts do not provide the linux/limits.h header required for
> conmakehash. To address this, ensure that usr/include is included in
> the conmakehash HOSTCFLAGS. This will provide the necessary header for
> successful compilation on macOS.
>
> Fixes error:
> HOSTCC  drivers/tty/vt/conmakehash - due to target missing
>   clang -Wp,-MMD,drivers/tty/vt/.conmakehash.d -Wall
> -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
> -std=gnu11   -I ./scripts/include     -o drivers/tty/vt/conmakehash
> drivers/tty/vt/conmakehash.c
> drivers/tty/vt/conmakehash.c:15:10: fatal error: 'linux/
>    limits.h' file not found 15 | #include <linux/limits.h>    |
>    ^~~~~~~~~~~~~~~~


The error is reported at line 15 of drivers/tty/vt/conmakehash.c


The line 15 is #include <stdlib.h>:

https://github.com/torvalds/linux/blob/v6.11-rc1/drivers/tty/vt/conmakehash.c#L15


So, host programs cannot include <stdlib.h> on your build machine.



drivers/tty/vt/conmakehash.c has only 5 include directives:

#include <stdio.h>
#include <stdlib.h>
#include <sysexits.h>
#include <string.h>
#include <ctype.h>


You cannot build this, your build machine cannot build anything.









> 1 error generated.
> make[5]: *** [scripts/Makefile.host:116: drivers/tty/vt/conmakehash]
> Error 1
> make[4]: *** [scripts/Makefile.build:485: drivers/tty/vt] Error 2
> make[3]: *** [scripts/Makefile.build:485: drivers/tty] Error 2
> make[2]: *** [scripts/Makefile.build:485: drivers] Error 2
> make[1]: *** [/Volumes/src/kernel/linux-next/Makefile:1925: .] Error 2
> make: *** [Makefile:224: __sub-make] Error 2
>
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
>  drivers/tty/vt/Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/vt/Makefile b/drivers/tty/vt/Makefile
> index 2c8ce8b592ed..d266895357e5 100644
> --- a/drivers/tty/vt/Makefile
> +++ b/drivers/tty/vt/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_CONSOLE_TRANSLATIONS)    += consolemap.o consolemap_deftbl.o
>  clean-files := consolemap_deftbl.c defkeymap.c
>
>  hostprogs += conmakehash
> +HOSTCFLAGS_conmakehash.o = -I$(srctree)/usr/include
>
>  quiet_cmd_conmk = CONMK   $@
>        cmd_conmk = $(obj)/conmakehash $< > $@
>
> --
> Git-146)
>
>


--
Best Regards
Masahiro Yamada

Re: [PATCH 11/12] tty/vt: conmakehash requires linux/limits.h

[Daniel Gomez (Samsung)]

On Fri, Aug 9, 2024 at 2:15 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Wed, Aug 7, 2024 at 8:10 AM Daniel Gomez via B4 Relay
> <devnull+da.gomez.samsung.com@kernel.org> wrote:
> >
> > From: Daniel Gomez <da.gomez@samsung.com>
> >
> > macOS hosts do not provide the linux/limits.h header required for
> > conmakehash. To address this, ensure that usr/include is included in
> > the conmakehash HOSTCFLAGS. This will provide the necessary header for
> > successful compilation on macOS.
> >
> > Fixes error:
> > HOSTCC  drivers/tty/vt/conmakehash - due to target missing
> >   clang -Wp,-MMD,drivers/tty/vt/.conmakehash.d -Wall
> > -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
> > -std=gnu11   -I ./scripts/include     -o drivers/tty/vt/conmakehash
> > drivers/tty/vt/conmakehash.c
> > drivers/tty/vt/conmakehash.c:15:10: fatal error: 'linux/
> >    limits.h' file not found 15 | #include <linux/limits.h>    |
> >    ^~~~~~~~~~~~~~~~
>
>
> The error is reported at line 15 of drivers/tty/vt/conmakehash.c
>
>
> The line 15 is #include <stdlib.h>:
>
> https://github.com/torvalds/linux/blob/v6.11-rc1/drivers/tty/vt/conmakehash.c#L15

The patches were sent using the latest linux-next at the moment of
sending, so next-20240806.
B4 adds the baseline [1] used at the bottom.

[1] base-commit: 1e391b34f6aa043c7afa40a2103163a0ef06d179

So line 15 is linux/limits.h header in this case:
https://github.com/torvalds/linux/blob/1e391b34f6aa043c7afa40a2103163a0ef06d179/drivers/tty/vt/conmakehash.c#L15
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/vt/conmakehash.c?h=1e391b34f6aa043c7afa40a2103163a0ef06d179#n15

This patch adds the header:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/tty/vt/conmakehash.c?h=next-20240809&id=6e20753da6bc651e02378a0cdb78f16c42098c88

>
>
> So, host programs cannot include <stdlib.h> on your build machine.
>
>
>
> drivers/tty/vt/conmakehash.c has only 5 include directives:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sysexits.h>
> #include <string.h>
> #include <ctype.h>
>
>
> You cannot build this, your build machine cannot build anything.
>
>
>
>
>
>
>
>
>
> > 1 error generated.
> > make[5]: *** [scripts/Makefile.host:116: drivers/tty/vt/conmakehash]
> > Error 1
> > make[4]: *** [scripts/Makefile.build:485: drivers/tty/vt] Error 2
> > make[3]: *** [scripts/Makefile.build:485: drivers/tty] Error 2
> > make[2]: *** [scripts/Makefile.build:485: drivers] Error 2
> > make[1]: *** [/Volumes/src/kernel/linux-next/Makefile:1925: .] Error 2
> > make: *** [Makefile:224: __sub-make] Error 2
> >
> > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > ---
> >  drivers/tty/vt/Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/tty/vt/Makefile b/drivers/tty/vt/Makefile
> > index 2c8ce8b592ed..d266895357e5 100644
> > --- a/drivers/tty/vt/Makefile
> > +++ b/drivers/tty/vt/Makefile
> > @@ -13,6 +13,7 @@ obj-$(CONFIG_CONSOLE_TRANSLATIONS)    += consolemap.o consolemap_deftbl.o
> >  clean-files := consolemap_deftbl.c defkeymap.c
> >
> >  hostprogs += conmakehash
> > +HOSTCFLAGS_conmakehash.o = -I$(srctree)/usr/include
> >
> >  quiet_cmd_conmk = CONMK   $@
> >        cmd_conmk = $(obj)/conmakehash $< > $@
> >
> > --
> > Git-146)
> >
> >
>
>
> --
> Best Regards
> Masahiro Yamada

[PATCH 12/12] scripts/kallsyms: add compatibility support for macos

[Daniel Gomez via B4 Relay]

From: Daniel Gomez <da.gomez@samsung.com>

Commit 67bf347ba924 ("kbuild: remove PROVIDE() for kallsyms symbols")
introduces the use of scripts/kallsyms with /dev/null as input to
generate the kernel symbols file. This results in getline() returning
ENOTTY as the errno value on macOS hosts. To handle this different
behavior, add a specific #ifdef condition for macOS.

Fixes:
+ scripts/kallsyms --base-relative /dev/null
read_symbol: Inappropriate ioctl for device
make[1]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1
make: *** [Makefile:1172: vmlinux] Error 2

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 scripts/kallsyms.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 0ed873491bf5..cb200120a072 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -130,7 +130,11 @@ static struct sym_entry *read_symbol(FILE *in, char **buf, size_t *buf_len)
 	errno = 0;
 	readlen = getline(buf, buf_len, in);
 	if (readlen < 0) {
+#ifndef __APPLE__
 		if (errno) {
+#else
+		if (errno && errno != ENOTTY) {
+#endif
 			perror("read_symbol");
 			exit(EXIT_FAILURE);
 		}

-- 
Git-146)

Re: [PATCH 00/12] Enable build system on macOS hosts

[Greg Kroah-Hartman]

On Wed, Aug 07, 2024 at 01:09:14AM +0200, Daniel Gomez via B4 Relay wrote:
> This patch set allows for building the Linux kernel for arm64 in macOS with
> LLVM.

Is this a requirement somewhere that this must work?  It seems like an
odd request, what workflows require cross-operating-system builds like
this?

thanks,

greg k-h

Re: [PATCH 00/12] Enable build system on macOS hosts

[Daniel Gomez]

On Wed, Aug 07, 2024 at 01:01:08PM GMT, Greg Kroah-Hartman wrote:
> On Wed, Aug 07, 2024 at 01:09:14AM +0200, Daniel Gomez via B4 Relay wrote:
> > This patch set allows for building the Linux kernel for arm64 in macOS with
> > LLVM.
> 
> Is this a requirement somewhere that this must work?  It seems like an
> odd request, what workflows require cross-operating-system builds like
> this?

This isn't a requirement, but it would, for example, support workflows for QEMU
users and developers on macOS. They could build/compile the kernel natively and
use it to launch QEMU instances, simplifying their process.

> 
> thanks,
> 
> greg k-h

Re: [PATCH 00/12] Enable build system on macOS hosts

[Greg Kroah-Hartman]

On Wed, Aug 07, 2024 at 01:56:38PM +0000, Daniel Gomez wrote:
> On Wed, Aug 07, 2024 at 01:01:08PM GMT, Greg Kroah-Hartman wrote:
> > On Wed, Aug 07, 2024 at 01:09:14AM +0200, Daniel Gomez via B4 Relay wrote:
> > > This patch set allows for building the Linux kernel for arm64 in macOS with
> > > LLVM.
> > 
> > Is this a requirement somewhere that this must work?  It seems like an
> > odd request, what workflows require cross-operating-system builds like
> > this?
> 
> This isn't a requirement, but it would, for example, support workflows for QEMU
> users and developers on macOS. They could build/compile the kernel natively and
> use it to launch QEMU instances, simplifying their process.

But that's not a real workload of anyone?  How often does this ever come
up?  Who is going to maintain this cross-build functionality over time?

thanks,

greg k-h

Re: [PATCH 00/12] Enable build system on macOS hosts

[Barry Song]

On Thu, Aug 8, 2024 at 2:20 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Aug 07, 2024 at 01:56:38PM +0000, Daniel Gomez wrote:
> > On Wed, Aug 07, 2024 at 01:01:08PM GMT, Greg Kroah-Hartman wrote:
> > > On Wed, Aug 07, 2024 at 01:09:14AM +0200, Daniel Gomez via B4 Relay wrote:
> > > > This patch set allows for building the Linux kernel for arm64 in macOS with
> > > > LLVM.
> > >
> > > Is this a requirement somewhere that this must work?  It seems like an
> > > odd request, what workflows require cross-operating-system builds like
> > > this?
> >
> > This isn't a requirement, but it would, for example, support workflows for QEMU
> > users and developers on macOS. They could build/compile the kernel natively and
> > use it to launch QEMU instances, simplifying their process.
>
> But that's not a real workload of anyone?  How often does this ever come
> up?  Who is going to maintain this cross-build functionality over time?

it is a real workload of me,  i was running qemu-system-aarch64 on x86
and it was
pretty slow. so got a M3 pro to accelerate my development. frequently changing
kernel's source code, i am using qemu-system-aarch64 to do quick verification.

>
> thanks,
>
> greg k-h
>

Thanks
Barry

Re: [PATCH 00/12] Enable build system on macOS hosts

[Klaus Jensen]

On Aug 17 13:11, Barry Song wrote:
> On Thu, Aug 8, 2024 at 2:20 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Aug 07, 2024 at 01:56:38PM +0000, Daniel Gomez wrote:
> > > On Wed, Aug 07, 2024 at 01:01:08PM GMT, Greg Kroah-Hartman wrote:
> > > > On Wed, Aug 07, 2024 at 01:09:14AM +0200, Daniel Gomez via B4 Relay wrote:
> > > > > This patch set allows for building the Linux kernel for arm64 in macOS with
> > > > > LLVM.
> > > >
> > > > Is this a requirement somewhere that this must work?  It seems like an
> > > > odd request, what workflows require cross-operating-system builds like
> > > > this?
> > >
> > > This isn't a requirement, but it would, for example, support workflows for QEMU
> > > users and developers on macOS. They could build/compile the kernel natively and
> > > use it to launch QEMU instances, simplifying their process.
> >
> > But that's not a real workload of anyone?  How often does this ever come
> > up?  Who is going to maintain this cross-build functionality over time?
> 
> it is a real workload of me,  i was running qemu-system-aarch64 on x86
> and it was
> pretty slow. so got a M3 pro to accelerate my development. frequently changing
> kernel's source code, i am using qemu-system-aarch64 to do quick verification.
> 

Allow me to chime in as well. Working with qemu-system-aarch64 on an Mx
are a daily thing for me as well. Working with custom built kernels have
been a pain, and this really helps.

Re: [PATCH 00/12] Enable build system on macOS hosts

[Daniel Gomez]

On Wed, Aug 07, 2024 at 04:19:42PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 07, 2024 at 01:56:38PM +0000, Daniel Gomez wrote:
> > On Wed, Aug 07, 2024 at 01:01:08PM GMT, Greg Kroah-Hartman wrote:
> > > On Wed, Aug 07, 2024 at 01:09:14AM +0200, Daniel Gomez via B4 Relay wrote:
> > > > This patch set allows for building the Linux kernel for arm64 in macOS with
> > > > LLVM.
> > > 
> > > Is this a requirement somewhere that this must work?  It seems like an
> > > odd request, what workflows require cross-operating-system builds like
> > > this?
> > 
> > This isn't a requirement, but it would, for example, support workflows for QEMU
> > users and developers on macOS. They could build/compile the kernel natively and
> > use it to launch QEMU instances, simplifying their process.
> 
> But that's not a real workload of anyone?  How often does this ever come
> up?  Who is going to maintain this cross-build functionality over time?

The delta is becoming very small thanks to the latest patches from Masahiro.
Earlier this week (next-20240820) [1] I rebased the work with all the feedback
and the patch series has been reduced to 7.

For the maintenance part, I suggest keeping a CI to build and boot the lastest
linux-next tag available. I can set this up here [2] and take the responsability
for maintaining that. But I would be convenient to add documentation for it in
the LLVM section and mark this as 'experimental'. If that's okay, I will prepare
a v2 with this.

[1] https://github.com/SamsungDS/linux/commits/b4/macos-build-support/
[2] https://github.com/SamsungDS/linux

> 
> thanks,
> 
> greg k-h

Re: [PATCH 00/12] Enable build system on macOS hosts

[Greg Kroah-Hartman]

On Sat, Aug 24, 2024 at 12:37:36AM +0200, Daniel Gomez wrote:
> On Wed, Aug 07, 2024 at 04:19:42PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Aug 07, 2024 at 01:56:38PM +0000, Daniel Gomez wrote:
> > > On Wed, Aug 07, 2024 at 01:01:08PM GMT, Greg Kroah-Hartman wrote:
> > > > On Wed, Aug 07, 2024 at 01:09:14AM +0200, Daniel Gomez via B4 Relay wrote:
> > > > > This patch set allows for building the Linux kernel for arm64 in macOS with
> > > > > LLVM.
> > > > 
> > > > Is this a requirement somewhere that this must work?  It seems like an
> > > > odd request, what workflows require cross-operating-system builds like
> > > > this?
> > > 
> > > This isn't a requirement, but it would, for example, support workflows for QEMU
> > > users and developers on macOS. They could build/compile the kernel natively and
> > > use it to launch QEMU instances, simplifying their process.
> > 
> > But that's not a real workload of anyone?  How often does this ever come
> > up?  Who is going to maintain this cross-build functionality over time?
> 
> The delta is becoming very small thanks to the latest patches from Masahiro.
> Earlier this week (next-20240820) [1] I rebased the work with all the feedback
> and the patch series has been reduced to 7.
> 
> For the maintenance part, I suggest keeping a CI to build and boot the lastest
> linux-next tag available. I can set this up here [2] and take the responsability
> for maintaining that. But I would be convenient to add documentation for it in
> the LLVM section and mark this as 'experimental'. If that's okay, I will prepare
> a v2 with this.

Let's see what v2 looks like and go from there.

thanks,

greg k-h

Re: [PATCH 08/12] include: add elf.h support

[Greg Kroah-Hartman]

On Wed, Aug 07, 2024 at 01:09:22AM +0200, Daniel Gomez via B4 Relay wrote:
> From: Daniel Gomez <da.gomez@samsung.com>
> 
> Add a copy of elf/elf.h header from the GNU C Library (glibc), version
> glibc-2.40 into include/elf. Update Makefiles where elf.h header is used
> to ensure the compiler can find all necessary headers, for macOS host
> where these headers are not provided by the system.
> 
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
>  arch/arm64/kernel/pi/Makefile     |    1 +
>  arch/arm64/kernel/vdso32/Makefile |    1 +
>  arch/arm64/kvm/hyp/nvhe/Makefile  |    2 +-
>  include/elf/elf.h                 | 4491 +++++++++++++++++++++++++++++++++++++
>  scripts/Makefile                  |    3 +-
>  scripts/mod/Makefile              |    6 +
>  6 files changed, 4502 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kernel/pi/Makefile b/arch/arm64/kernel/pi/Makefile
> index 4d11a8c29181..eb782aaa6585 100644
> --- a/arch/arm64/kernel/pi/Makefile
> +++ b/arch/arm64/kernel/pi/Makefile
> @@ -20,6 +20,7 @@ KBUILD_CFLAGS	:= $(filter-out $(CC_FLAGS_SCS), $(KBUILD_CFLAGS))
>  KBUILD_CFLAGS	:= $(filter-out $(CC_FLAGS_LTO), $(KBUILD_CFLAGS))
>  
>  hostprogs	:= relacheck
> +HOSTCFLAGS_relacheck.o = -I$(srctree)/include/elf
>  
>  quiet_cmd_piobjcopy = $(quiet_cmd_objcopy)
>        cmd_piobjcopy = $(cmd_objcopy) && $(obj)/relacheck $(@) $(<)
> diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> index 25a2cb6317f3..e1ac384e6332 100644
> --- a/arch/arm64/kernel/vdso32/Makefile
> +++ b/arch/arm64/kernel/vdso32/Makefile
> @@ -107,6 +107,7 @@ VDSO_LDFLAGS += --orphan-handling=$(CONFIG_LD_ORPHAN_WARN_LEVEL)
>  # $(hostprogs) with $(obj)
>  munge := ../../../arm/vdso/vdsomunge
>  hostprogs := $(munge)
> +HOSTCFLAGS_$(munge).o = -I$(objtree)/include/elf
>  
>  c-obj-vdso := note.o
>  c-obj-vdso-gettimeofday := vgettimeofday.o
> diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
> index 782b34b004be..40541c0812bf 100644
> --- a/arch/arm64/kvm/hyp/nvhe/Makefile
> +++ b/arch/arm64/kvm/hyp/nvhe/Makefile
> @@ -15,7 +15,7 @@ ccflags-y += -fno-stack-protector	\
>  	     $(DISABLE_STACKLEAK_PLUGIN)
>  
>  hostprogs := gen-hyprel
> -HOST_EXTRACFLAGS += -I$(objtree)/include
> +HOST_EXTRACFLAGS += -I$(objtree)/include -I$(srctree)/include/elf
>  
>  lib-objs := clear_page.o copy_page.o memcpy.o memset.o
>  lib-objs := $(addprefix ../../../lib/, $(lib-objs))
> diff --git a/include/elf/elf.h b/include/elf/elf.h
> new file mode 100644
> index 000000000000..33aea7f743b8
> --- /dev/null
> +++ b/include/elf/elf.h
> @@ -0,0 +1,4491 @@
> +/* This file defines standard ELF types, structures, and macros.
> +   Copyright (C) 1995-2024 Free Software Foundation, Inc.
> +   This file is part of the GNU C Library.
> +
> +   The GNU C Library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   The GNU C Library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with the GNU C Library; if not, see
> +   <https://www.gnu.org/licenses/>.  */

I understand your want/need for this, but new files need a SPDX license
header instead of this type of license boilerplate.  Didn't glibc
already convert to SPDX?

Also, as this is not internal for the kernel, but rather for userspace
builds, shouldn't the include/ path be different?

thanks,

greg k-h

Re: [PATCH 08/12] include: add elf.h support

[Daniel Gomez]

On Wed, Aug 07, 2024 at 01:04:29PM GMT, Greg Kroah-Hartman wrote:
> On Wed, Aug 07, 2024 at 01:09:22AM +0200, Daniel Gomez via B4 Relay wrote:
> > From: Daniel Gomez <da.gomez@samsung.com>
> > 
> > Add a copy of elf/elf.h header from the GNU C Library (glibc), version
> > glibc-2.40 into include/elf. Update Makefiles where elf.h header is used
> > to ensure the compiler can find all necessary headers, for macOS host
> > where these headers are not provided by the system.
> > 
> > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > ---
> >  arch/arm64/kernel/pi/Makefile     |    1 +
> >  arch/arm64/kernel/vdso32/Makefile |    1 +
> >  arch/arm64/kvm/hyp/nvhe/Makefile  |    2 +-
> >  include/elf/elf.h                 | 4491 +++++++++++++++++++++++++++++++++++++
> >  scripts/Makefile                  |    3 +-
> >  scripts/mod/Makefile              |    6 +
> >  6 files changed, 4502 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/pi/Makefile b/arch/arm64/kernel/pi/Makefile
> > index 4d11a8c29181..eb782aaa6585 100644
> > --- a/arch/arm64/kernel/pi/Makefile
> > +++ b/arch/arm64/kernel/pi/Makefile
> > @@ -20,6 +20,7 @@ KBUILD_CFLAGS	:= $(filter-out $(CC_FLAGS_SCS), $(KBUILD_CFLAGS))
> >  KBUILD_CFLAGS	:= $(filter-out $(CC_FLAGS_LTO), $(KBUILD_CFLAGS))
> >  
> >  hostprogs	:= relacheck
> > +HOSTCFLAGS_relacheck.o = -I$(srctree)/include/elf
> >  
> >  quiet_cmd_piobjcopy = $(quiet_cmd_objcopy)
> >        cmd_piobjcopy = $(cmd_objcopy) && $(obj)/relacheck $(@) $(<)
> > diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> > index 25a2cb6317f3..e1ac384e6332 100644
> > --- a/arch/arm64/kernel/vdso32/Makefile
> > +++ b/arch/arm64/kernel/vdso32/Makefile
> > @@ -107,6 +107,7 @@ VDSO_LDFLAGS += --orphan-handling=$(CONFIG_LD_ORPHAN_WARN_LEVEL)
> >  # $(hostprogs) with $(obj)
> >  munge := ../../../arm/vdso/vdsomunge
> >  hostprogs := $(munge)
> > +HOSTCFLAGS_$(munge).o = -I$(objtree)/include/elf
> >  
> >  c-obj-vdso := note.o
> >  c-obj-vdso-gettimeofday := vgettimeofday.o
> > diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
> > index 782b34b004be..40541c0812bf 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/Makefile
> > +++ b/arch/arm64/kvm/hyp/nvhe/Makefile
> > @@ -15,7 +15,7 @@ ccflags-y += -fno-stack-protector	\
> >  	     $(DISABLE_STACKLEAK_PLUGIN)
> >  
> >  hostprogs := gen-hyprel
> > -HOST_EXTRACFLAGS += -I$(objtree)/include
> > +HOST_EXTRACFLAGS += -I$(objtree)/include -I$(srctree)/include/elf
> >  
> >  lib-objs := clear_page.o copy_page.o memcpy.o memset.o
> >  lib-objs := $(addprefix ../../../lib/, $(lib-objs))
> > diff --git a/include/elf/elf.h b/include/elf/elf.h
> > new file mode 100644
> > index 000000000000..33aea7f743b8
> > --- /dev/null
> > +++ b/include/elf/elf.h
> > @@ -0,0 +1,4491 @@
> > +/* This file defines standard ELF types, structures, and macros.
> > +   Copyright (C) 1995-2024 Free Software Foundation, Inc.
> > +   This file is part of the GNU C Library.
> > +
> > +   The GNU C Library is free software; you can redistribute it and/or
> > +   modify it under the terms of the GNU Lesser General Public
> > +   License as published by the Free Software Foundation; either
> > +   version 2.1 of the License, or (at your option) any later version.
> > +
> > +   The GNU C Library is distributed in the hope that it will be useful,
> > +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > +   Lesser General Public License for more details.
> > +
> > +   You should have received a copy of the GNU Lesser General Public
> > +   License along with the GNU C Library; if not, see
> > +   <https://www.gnu.org/licenses/>.  */
> 
> I understand your want/need for this, but new files need a SPDX license
> header instead of this type of license boilerplate.  Didn't glibc
> already convert to SPDX?

I don't think they've done the conversion. But I can add the SPDX header if we
move forward with the patch series, and ask them if they have any plan to adopt
the SPDX standard.

> 
> Also, as this is not internal for the kernel, but rather for userspace
> builds, shouldn't the include/ path be different?

Can you suggest an alternative path or provide documentation that could help
identify the correct location? Perhaps usr/include?

> 
> thanks,
> 
> greg k-h

Re: [PATCH 08/12] include: add elf.h support

[Greg Kroah-Hartman]

On Wed, Aug 07, 2024 at 02:13:57PM +0000, Daniel Gomez wrote:
> > Also, as this is not internal for the kernel, but rather for userspace
> > builds, shouldn't the include/ path be different?
> 
> Can you suggest an alternative path or provide documentation that could help
> identify the correct location? Perhaps usr/include?

That is better than the generic include path as you are attempting to
mix userspace and kernel headers in the same directory :(

Re: [PATCH 08/12] include: add elf.h support

[Nicolas Schier]

On Wed, Aug 07, 2024 at 04:18:54PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 07, 2024 at 02:13:57PM +0000, Daniel Gomez wrote:
> > > Also, as this is not internal for the kernel, but rather for userspace
> > > builds, shouldn't the include/ path be different?
> > 
> > Can you suggest an alternative path or provide documentation that could help
> > identify the correct location? Perhaps usr/include?
> 
> That is better than the generic include path as you are attempting to
> mix userspace and kernel headers in the same directory :(

Please keep in mind, that usr/include/ currently does not hold a single
header file but is used for dynamically composing the UAPI header tree.

In general, I do not like the idea of keeping a elf.h file here that
possibly is out-of-sync with the actual system's version (even though
elf.h should not see that much changes).  Might it be more helpful to
provide a "development kit" for Linux devs that need to build on MacOS
that provides necessary missing system header files, instead of merging
those into upstream?

Kind regards,
Nicolas

-- 
Nicolas

Re: [PATCH 08/12] include: add elf.h support

[Daniel Gomez]

On Wed, Aug 07, 2024 at 05:46:03PM +0200, Nicolas Schier wrote:
> On Wed, Aug 07, 2024 at 04:18:54PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Aug 07, 2024 at 02:13:57PM +0000, Daniel Gomez wrote:
> > > > Also, as this is not internal for the kernel, but rather for userspace
> > > > builds, shouldn't the include/ path be different?
> > > 
> > > Can you suggest an alternative path or provide documentation that could help
> > > identify the correct location? Perhaps usr/include?
> > 
> > That is better than the generic include path as you are attempting to
> > mix userspace and kernel headers in the same directory :(
> 
> Please keep in mind, that usr/include/ currently does not hold a single
> header file but is used for dynamically composing the UAPI header tree.
> 
> In general, I do not like the idea of keeping a elf.h file here that
> possibly is out-of-sync with the actual system's version (even though
> elf.h should not see that much changes).  Might it be more helpful to
> provide a "development kit" for Linux devs that need to build on MacOS
> that provides necessary missing system header files, instead of merging
> those into upstream?

I took this suggestion and tried pushing a Homebrew formula/package here [1].
I think I chose a wrong name and maybe something like "development kit" would
have been better. However, would it be possible instead to include the *.rb file
in the scripts/ directory? So users of this can generate the development kit in
their environments. I would maintain the script to keep it in sync with the
required glibc version for the latest kernel version.

[1] https://github.com/Homebrew/homebrew-core/pull/181885

> 
> Kind regards,
> Nicolas
> 
> -- 
> Nicolas

Re: [PATCH 08/12] include: add elf.h support

[Nicolas Schier]

On Sat, Aug 24, 2024 at 12:54:50AM +0200 Daniel Gomez wrote:
> On Wed, Aug 07, 2024 at 05:46:03PM +0200, Nicolas Schier wrote:
> > On Wed, Aug 07, 2024 at 04:18:54PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Aug 07, 2024 at 02:13:57PM +0000, Daniel Gomez wrote:
> > > > > Also, as this is not internal for the kernel, but rather for userspace
> > > > > builds, shouldn't the include/ path be different?
> > > > 
> > > > Can you suggest an alternative path or provide documentation that could help
> > > > identify the correct location? Perhaps usr/include?
> > > 
> > > That is better than the generic include path as you are attempting to
> > > mix userspace and kernel headers in the same directory :(
> > 
> > Please keep in mind, that usr/include/ currently does not hold a single
> > header file but is used for dynamically composing the UAPI header tree.
> > 
> > In general, I do not like the idea of keeping a elf.h file here that
> > possibly is out-of-sync with the actual system's version (even though
> > elf.h should not see that much changes).  Might it be more helpful to
> > provide a "development kit" for Linux devs that need to build on MacOS
> > that provides necessary missing system header files, instead of merging
> > those into upstream?
> 
> I took this suggestion and tried pushing a Homebrew formula/package here [1].
> I think I chose a wrong name and maybe something like "development kit" would
> have been better. However, would it be possible instead to include the *.rb file
> in the scripts/ directory? So users of this can generate the development kit in
> their environments. I would maintain the script to keep it in sync with the
> required glibc version for the latest kernel version.
> 
> [1] https://github.com/Homebrew/homebrew-core/pull/181885

I think it sounds sensible to hold that formula file in the upstream tree.  But
I am not sure if scripts/ is the best location.

Masahiro, what do you think?

Kind regards,
Nicolas

Re: [PATCH 08/12] include: add elf.h support

[Masahiro Yamada]

On Sat, Aug 31, 2024 at 4:54 AM Nicolas Schier <nicolas@fjasle.eu> wrote:
>
> On Sat, Aug 24, 2024 at 12:54:50AM +0200 Daniel Gomez wrote:
> > On Wed, Aug 07, 2024 at 05:46:03PM +0200, Nicolas Schier wrote:
> > > On Wed, Aug 07, 2024 at 04:18:54PM +0200, Greg Kroah-Hartman wrote:
> > > > On Wed, Aug 07, 2024 at 02:13:57PM +0000, Daniel Gomez wrote:
> > > > > > Also, as this is not internal for the kernel, but rather for userspace
> > > > > > builds, shouldn't the include/ path be different?
> > > > >
> > > > > Can you suggest an alternative path or provide documentation that could help
> > > > > identify the correct location? Perhaps usr/include?
> > > >
> > > > That is better than the generic include path as you are attempting to
> > > > mix userspace and kernel headers in the same directory :(
> > >
> > > Please keep in mind, that usr/include/ currently does not hold a single
> > > header file but is used for dynamically composing the UAPI header tree.
> > >
> > > In general, I do not like the idea of keeping a elf.h file here that
> > > possibly is out-of-sync with the actual system's version (even though
> > > elf.h should not see that much changes).  Might it be more helpful to
> > > provide a "development kit" for Linux devs that need to build on MacOS
> > > that provides necessary missing system header files, instead of merging
> > > those into upstream?
> >
> > I took this suggestion and tried pushing a Homebrew formula/package here [1].
> > I think I chose a wrong name and maybe something like "development kit" would
> > have been better. However, would it be possible instead to include the *.rb file
> > in the scripts/ directory? So users of this can generate the development kit in
> > their environments. I would maintain the script to keep it in sync with the
> > required glibc version for the latest kernel version.
> >
> > [1] https://github.com/Homebrew/homebrew-core/pull/181885
>
> I think it sounds sensible to hold that formula file in the upstream tree.  But
> I am not sure if scripts/ is the best location.
>
> Masahiro, what do you think?


I do not know much about the homebrew, but why does the upstream
kernel need to merge such masOS stuff?



>
> Kind regards,
> Nicolas



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 08/12] include: add elf.h support

[Daniel Gomez]

On Mon, Sep 02, 2024 at 01:15:01AM +0900, Masahiro Yamada wrote:
> On Sat, Aug 31, 2024 at 4:54 AM Nicolas Schier <nicolas@fjasle.eu> wrote:
> >
> > On Sat, Aug 24, 2024 at 12:54:50AM +0200 Daniel Gomez wrote:
> > > On Wed, Aug 07, 2024 at 05:46:03PM +0200, Nicolas Schier wrote:
> > > > On Wed, Aug 07, 2024 at 04:18:54PM +0200, Greg Kroah-Hartman wrote:
> > > > > On Wed, Aug 07, 2024 at 02:13:57PM +0000, Daniel Gomez wrote:
> > > > > > > Also, as this is not internal for the kernel, but rather for userspace
> > > > > > > builds, shouldn't the include/ path be different?
> > > > > >
> > > > > > Can you suggest an alternative path or provide documentation that could help
> > > > > > identify the correct location? Perhaps usr/include?
> > > > >
> > > > > That is better than the generic include path as you are attempting to
> > > > > mix userspace and kernel headers in the same directory :(
> > > >
> > > > Please keep in mind, that usr/include/ currently does not hold a single
> > > > header file but is used for dynamically composing the UAPI header tree.
> > > >
> > > > In general, I do not like the idea of keeping a elf.h file here that
> > > > possibly is out-of-sync with the actual system's version (even though
> > > > elf.h should not see that much changes).  Might it be more helpful to
> > > > provide a "development kit" for Linux devs that need to build on MacOS
> > > > that provides necessary missing system header files, instead of merging
> > > > those into upstream?
> > >
> > > I took this suggestion and tried pushing a Homebrew formula/package here [1].
> > > I think I chose a wrong name and maybe something like "development kit" would
> > > have been better. However, would it be possible instead to include the *.rb file
> > > in the scripts/ directory? So users of this can generate the development kit in
> > > their environments. I would maintain the script to keep it in sync with the
> > > required glibc version for the latest kernel version.
> > >
> > > [1] https://protect2.fireeye.com/v1/url?k=96027706-f7896236-9603fc49-000babffaa23-452f645d7a72e234&q=1&e=343dd31c-5e5b-4b09-8ee5-6c59a1ff826e&u=https%3A%2F%2Fgithub.com%2FHomebrew%2Fhomebrew-core%2Fpull%2F181885
> >
> > I think it sounds sensible to hold that formula file in the upstream tree.  But
> > I am not sure if scripts/ is the best location.
> >
> > Masahiro, what do you think?
> 
> 
> I do not know much about the homebrew, but why does the upstream
> kernel need to merge such masOS stuff?

The missing headers (in macOS) need to be provided somehow. One way can be
having the formula (*.rb file) in-tree, so users of this can install them in
their systems. This would also require to have a tarball with the missing
headers either in-tree or somewhere accessible so it can be fetched.

To avoid having the formula and a tarball in-tree, I've created a Homebrew Tap
(3rd-Party Repository) called 'Bee Headers Project' [1][2][3] that can provision
the missing headers. The project provides a bee-headers package and formula
that will install byteswap.h, elf.h and endian.h in the user's system Hombrew
directory. It also provides a *.pc file so pkg-config can be used to find the
location of these headers. I have a v2 with this solution ready, perhaps is
easier to discuss this with the code.

I think we can extend the same package and include extra headers if we need
more in the future. I see for x86_64 asm/types.h and others might be required.
The bee-headers package can then be the repository to place and distribute them.

Please, let me know if you think of an alternative solution, I can give a try
and explore.

[1] Project:
https://github.com/bee-headers
[2] Headers repository:
https://github.com/bee-headers/headers.git
[3] Homebrew Tap formula:
https://github.com/bee-headers/homebrew-bee-headers.git


> 
> 
> 
> >
> > Kind regards,
> > Nicolas
> 
> 
> 
> -- 
> Best Regards
> Masahiro Yamada

Re: [PATCH 08/12] include: add elf.h support

[Masahiro Yamada]

On Thu, Sep 5, 2024 at 5:56 PM Daniel Gomez <da.gomez@samsung.com> wrote:
>
> On Mon, Sep 02, 2024 at 01:15:01AM +0900, Masahiro Yamada wrote:
> > On Sat, Aug 31, 2024 at 4:54 AM Nicolas Schier <nicolas@fjasle.eu> wrote:
> > >
> > > On Sat, Aug 24, 2024 at 12:54:50AM +0200 Daniel Gomez wrote:
> > > > On Wed, Aug 07, 2024 at 05:46:03PM +0200, Nicolas Schier wrote:
> > > > > On Wed, Aug 07, 2024 at 04:18:54PM +0200, Greg Kroah-Hartman wrote:
> > > > > > On Wed, Aug 07, 2024 at 02:13:57PM +0000, Daniel Gomez wrote:
> > > > > > > > Also, as this is not internal for the kernel, but rather for userspace
> > > > > > > > builds, shouldn't the include/ path be different?
> > > > > > >
> > > > > > > Can you suggest an alternative path or provide documentation that could help
> > > > > > > identify the correct location? Perhaps usr/include?
> > > > > >
> > > > > > That is better than the generic include path as you are attempting to
> > > > > > mix userspace and kernel headers in the same directory :(
> > > > >
> > > > > Please keep in mind, that usr/include/ currently does not hold a single
> > > > > header file but is used for dynamically composing the UAPI header tree.
> > > > >
> > > > > In general, I do not like the idea of keeping a elf.h file here that
> > > > > possibly is out-of-sync with the actual system's version (even though
> > > > > elf.h should not see that much changes).  Might it be more helpful to
> > > > > provide a "development kit" for Linux devs that need to build on MacOS
> > > > > that provides necessary missing system header files, instead of merging
> > > > > those into upstream?
> > > >
> > > > I took this suggestion and tried pushing a Homebrew formula/package here [1].
> > > > I think I chose a wrong name and maybe something like "development kit" would
> > > > have been better. However, would it be possible instead to include the *.rb file
> > > > in the scripts/ directory? So users of this can generate the development kit in
> > > > their environments. I would maintain the script to keep it in sync with the
> > > > required glibc version for the latest kernel version.
> > > >
> > > > [1] https://protect2.fireeye.com/v1/url?k=96027706-f7896236-9603fc49-000babffaa23-452f645d7a72e234&q=1&e=343dd31c-5e5b-4b09-8ee5-6c59a1ff826e&u=https%3A%2F%2Fgithub.com%2FHomebrew%2Fhomebrew-core%2Fpull%2F181885
> > >
> > > I think it sounds sensible to hold that formula file in the upstream tree.  But
> > > I am not sure if scripts/ is the best location.
> > >
> > > Masahiro, what do you think?
> >
> >
> > I do not know much about the homebrew, but why does the upstream
> > kernel need to merge such masOS stuff?
>
> The missing headers (in macOS) need to be provided somehow. One way can be
> having the formula (*.rb file) in-tree, so users of this can install them in
> their systems. This would also require to have a tarball with the missing
> headers either in-tree or somewhere accessible so it can be fetched.
>
> To avoid having the formula and a tarball in-tree, I've created a Homebrew Tap
> (3rd-Party Repository) called 'Bee Headers Project' [1][2][3] that can provision
> the missing headers. The project provides a bee-headers package and formula
> that will install byteswap.h, elf.h and endian.h in the user's system Hombrew
> directory. It also provides a *.pc file so pkg-config can be used to find the
> location of these headers. I have a v2 with this solution ready, perhaps is
> easier to discuss this with the code.


It is up to you what project you start in Github.

Then, what do you need to submit v2 for this?





>
> I think we can extend the same package and include extra headers if we need
> more in the future. I see for x86_64 asm/types.h and others might be required.
> The bee-headers package can then be the repository to place and distribute them.
>
> Please, let me know if you think of an alternative solution, I can give a try
> and explore.
>
> [1] Project:
> https://github.com/bee-headers
> [2] Headers repository:
> https://github.com/bee-headers/headers.git
> [3] Homebrew Tap formula:
> https://github.com/bee-headers/homebrew-bee-headers.git
>
>
> >
> >
> >
> > >
> > > Kind regards,
> > > Nicolas
> >
> >
> >
> > --
> > Best Regards
> > Masahiro Yamada



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 08/12] include: add elf.h support

[Daniel Gomez]

On Fri, Sep 06, 2024 at 08:58:15AM +0900, Masahiro Yamada wrote:
> On Thu, Sep 5, 2024 at 5:56 PM Daniel Gomez <da.gomez@samsung.com> wrote:
> >
> > On Mon, Sep 02, 2024 at 01:15:01AM +0900, Masahiro Yamada wrote:
> > > On Sat, Aug 31, 2024 at 4:54 AM Nicolas Schier <nicolas@fjasle.eu> wrote:
> > > >
> > > > On Sat, Aug 24, 2024 at 12:54:50AM +0200 Daniel Gomez wrote:
> > > > > On Wed, Aug 07, 2024 at 05:46:03PM +0200, Nicolas Schier wrote:
> > > > > > On Wed, Aug 07, 2024 at 04:18:54PM +0200, Greg Kroah-Hartman wrote:
> > > > > > > On Wed, Aug 07, 2024 at 02:13:57PM +0000, Daniel Gomez wrote:
> > > > > > > > > Also, as this is not internal for the kernel, but rather for userspace
> > > > > > > > > builds, shouldn't the include/ path be different?
> > > > > > > >
> > > > > > > > Can you suggest an alternative path or provide documentation that could help
> > > > > > > > identify the correct location? Perhaps usr/include?
> > > > > > >
> > > > > > > That is better than the generic include path as you are attempting to
> > > > > > > mix userspace and kernel headers in the same directory :(
> > > > > >
> > > > > > Please keep in mind, that usr/include/ currently does not hold a single
> > > > > > header file but is used for dynamically composing the UAPI header tree.
> > > > > >
> > > > > > In general, I do not like the idea of keeping a elf.h file here that
> > > > > > possibly is out-of-sync with the actual system's version (even though
> > > > > > elf.h should not see that much changes).  Might it be more helpful to
> > > > > > provide a "development kit" for Linux devs that need to build on MacOS
> > > > > > that provides necessary missing system header files, instead of merging
> > > > > > those into upstream?
> > > > >
> > > > > I took this suggestion and tried pushing a Homebrew formula/package here [1].
> > > > > I think I chose a wrong name and maybe something like "development kit" would
> > > > > have been better. However, would it be possible instead to include the *.rb file
> > > > > in the scripts/ directory? So users of this can generate the development kit in
> > > > > their environments. I would maintain the script to keep it in sync with the
> > > > > required glibc version for the latest kernel version.
> > > > >
> > > > > [1] https://protect2.fireeye.com/v1/url?k=96027706-f7896236-9603fc49-000babffaa23-452f645d7a72e234&q=1&e=343dd31c-5e5b-4b09-8ee5-6c59a1ff826e&u=https%3A%2F%2Fgithub.com%2FHomebrew%2Fhomebrew-core%2Fpull%2F181885
> > > >
> > > > I think it sounds sensible to hold that formula file in the upstream tree.  But
> > > > I am not sure if scripts/ is the best location.
> > > >
> > > > Masahiro, what do you think?
> > >
> > >
> > > I do not know much about the homebrew, but why does the upstream
> > > kernel need to merge such masOS stuff?
> >
> > The missing headers (in macOS) need to be provided somehow. One way can be
> > having the formula (*.rb file) in-tree, so users of this can install them in
> > their systems. This would also require to have a tarball with the missing
> > headers either in-tree or somewhere accessible so it can be fetched.
> >
> > To avoid having the formula and a tarball in-tree, I've created a Homebrew Tap
> > (3rd-Party Repository) called 'Bee Headers Project' [1][2][3] that can provision
> > the missing headers. The project provides a bee-headers package and formula
> > that will install byteswap.h, elf.h and endian.h in the user's system Hombrew
> > directory. It also provides a *.pc file so pkg-config can be used to find the
> > location of these headers. I have a v2 with this solution ready, perhaps is
> > easier to discuss this with the code.
> 
> 
> It is up to you what project you start in Github.
> 
> Then, what do you need to submit v2 for this?

I'll just include a reference in the documentation.

And will send the v2 later today.

> 
> 
> 
> 
> 
> >
> > I think we can extend the same package and include extra headers if we need
> > more in the future. I see for x86_64 asm/types.h and others might be required.
> > The bee-headers package can then be the repository to place and distribute them.
> >
> > Please, let me know if you think of an alternative solution, I can give a try
> > and explore.
> >
> > [1] Project:
> > https://protect2.fireeye.com/v1/url?k=8f1b9871-ee908d54-8f1a133e-74fe485cbff6-b9b8f875df8b37c5&q=1&e=860f3982-d1e4-4fcb-ab79-f181bb7fcda3&u=https%3A%2F%2Fgithub.com%2Fbee-headers
> > [2] Headers repository:
> > https://protect2.fireeye.com/v1/url?k=7c995f7b-1d124a5e-7c98d434-74fe485cbff6-a20d4e643f5978f8&q=1&e=860f3982-d1e4-4fcb-ab79-f181bb7fcda3&u=https%3A%2F%2Fgithub.com%2Fbee-headers%2Fheaders.git
> > [3] Homebrew Tap formula:
> > https://protect2.fireeye.com/v1/url?k=148f40fc-750455d9-148ecbb3-74fe485cbff6-5d795246adb22931&q=1&e=860f3982-d1e4-4fcb-ab79-f181bb7fcda3&u=https%3A%2F%2Fgithub.com%2Fbee-headers%2Fhomebrew-bee-headers.git
> >
> >
> > >
> > >
> > >
> > > >
> > > > Kind regards,
> > > > Nicolas
> > >
> > >
> > >
> > > --
> > > Best Regards
> > > Masahiro Yamada
> 
> 
> 
> -- 
> Best Regards
> Masahiro Yamada