[PATCH 0/4] kbuild: cross-compile linux-headers package

[PATCH 0/4] kbuild: cross-compile linux-headers package

[Masahiro Yamada]

This series makes cross-built linux-headers package usable in the
installed system. Currently, host programs in it are built for the
build machine instead of the target architecture.

The first two patches refactors modpost. The endianness in modpost is
currently determined at compile-time, but the build machine cannot
execute scripts/mod/mk_elfconfig compiled for a forein architecture.

The last patch rebuilds scripts/ for the target architecture.



Masahiro Yamada (4):
  modpost: remove unused HOST_ELFCLASS
  modpost: detect endianness on run-time
  kbuild: slim down package for building external modules
  kbuild: cross-compile linux-headers package when possible

 scripts/mod/mk_elfconfig.c           | 25 -------------
 scripts/mod/modpost.c                | 36 +++++++++++++++++++
 scripts/mod/modpost.h                | 13 +++----
 scripts/package/install-extmod-build | 54 +++++++++++++++++++++++++---
 4 files changed, 89 insertions(+), 39 deletions(-)

-- 
2.43.0

[PATCH 1/4] modpost: remove unused HOST_ELFCLASS

[Masahiro Yamada]

HOST_ELFCLASS is output to elfconfig.h, but it is not used in modpost.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---

 scripts/mod/mk_elfconfig.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/scripts/mod/mk_elfconfig.c b/scripts/mod/mk_elfconfig.c
index 680eade89be1..aca96b3aada0 100644
--- a/scripts/mod/mk_elfconfig.c
+++ b/scripts/mod/mk_elfconfig.c
@@ -39,12 +39,6 @@ main(int argc, char **argv)
 		exit(1);
 	}
 
-	if (sizeof(unsigned long) == 4) {
-		printf("#define HOST_ELFCLASS ELFCLASS32\n");
-	} else if (sizeof(unsigned long) == 8) {
-		printf("#define HOST_ELFCLASS ELFCLASS64\n");
-	}
-
 	endian_test.s = 0x0102;
 	if (memcmp(endian_test.c, "\x01\x02", 2) == 0)
 		printf("#define HOST_ELFDATA ELFDATA2MSB\n");
-- 
2.43.0

[PATCH 2/4] modpost: detect endianness on run-time

[Masahiro Yamada]

Endianness is currently detected on compile-time, but we can defer this
until run-time. This change avoids re-executing scripts/mod/mk_elfconfig
even if modpost in the linux-headers package needs to be rebuilt for a
foreign architecture.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---

 scripts/mod/mk_elfconfig.c | 19 -------------------
 scripts/mod/modpost.c      | 36 ++++++++++++++++++++++++++++++++++++
 scripts/mod/modpost.h      | 13 ++++---------
 3 files changed, 40 insertions(+), 28 deletions(-)

diff --git a/scripts/mod/mk_elfconfig.c b/scripts/mod/mk_elfconfig.c
index aca96b3aada0..e8cee4e4bc73 100644
--- a/scripts/mod/mk_elfconfig.c
+++ b/scripts/mod/mk_elfconfig.c
@@ -8,7 +8,6 @@ int
 main(int argc, char **argv)
 {
 	unsigned char ei[EI_NIDENT];
-	union { short s; char c[2]; } endian_test;
 
 	if (fread(ei, 1, EI_NIDENT, stdin) != EI_NIDENT) {
 		fprintf(stderr, "Error: input truncated\n");
@@ -28,24 +27,6 @@ main(int argc, char **argv)
 	default:
 		exit(1);
 	}
-	switch (ei[EI_DATA]) {
-	case ELFDATA2LSB:
-		printf("#define KERNEL_ELFDATA ELFDATA2LSB\n");
-		break;
-	case ELFDATA2MSB:
-		printf("#define KERNEL_ELFDATA ELFDATA2MSB\n");
-		break;
-	default:
-		exit(1);
-	}
-
-	endian_test.s = 0x0102;
-	if (memcmp(endian_test.c, "\x01\x02", 2) == 0)
-		printf("#define HOST_ELFDATA ELFDATA2MSB\n");
-	else if (memcmp(endian_test.c, "\x02\x01", 2) == 0)
-		printf("#define HOST_ELFDATA ELFDATA2LSB\n");
-	else
-		exit(1);
 
 	return 0;
 }
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index d16d0ace2775..f492fbeed300 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -50,6 +50,9 @@ static bool error_occurred;
 
 static bool extra_warn;
 
+bool target_is_big_endian;
+bool host_is_big_endian;
+
 /*
  * Cut off the warnings when there are too many. This typically occurs when
  * vmlinux is missing. ('make modules' without building vmlinux.)
@@ -438,6 +441,18 @@ static int parse_elf(struct elf_info *info, const char *filename)
 		/* Not an ELF file - silently ignore it */
 		return 0;
 	}
+
+	switch (hdr->e_ident[EI_DATA]) {
+	case ELFDATA2LSB:
+		target_is_big_endian = false;
+		break;
+	case ELFDATA2MSB:
+		target_is_big_endian = true;
+		break;
+	default:
+		fatal("kernel endian is unknown\n");
+	}
+
 	/* Fix endianness in ELF header */
 	hdr->e_type      = TO_NATIVE(hdr->e_type);
 	hdr->e_machine   = TO_NATIVE(hdr->e_machine);
@@ -2117,6 +2132,25 @@ struct dump_list {
 	const char *file;
 };
 
+static void check_host_endian(void)
+{
+	static const union {
+		short s;
+		char c[2];
+	} endian_test = { .c = {0x01, 0x02} };
+
+	switch (endian_test.s) {
+	case 0x0102:
+		host_is_big_endian = true;
+		break;
+	case 0x0201:
+		host_is_big_endian = false;
+		break;
+	default:
+		fatal("Unknown host endian\n");
+	}
+}
+
 int main(int argc, char **argv)
 {
 	struct module *mod;
@@ -2181,6 +2215,8 @@ int main(int argc, char **argv)
 		}
 	}
 
+	check_host_endian();
+
 	list_for_each_entry_safe(dl, dl2, &dump_lists, list) {
 		read_dump(dl->file);
 		list_del(&dl->list);
diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
index 58197b34a3c8..54ba9431713f 100644
--- a/scripts/mod/modpost.h
+++ b/scripts/mod/modpost.h
@@ -62,15 +62,8 @@
 		    x); \
 })
 
-#if KERNEL_ELFDATA != HOST_ELFDATA
-
-#define TO_NATIVE(x) (bswap(x))
-
-#else /* endianness matches */
-
-#define TO_NATIVE(x) (x)
-
-#endif
+#define TO_NATIVE(x)	\
+	(target_is_big_endian == host_is_big_endian ? x : bswap(x))
 
 #define NOFAIL(ptr)   do_nofail((ptr), #ptr)
 
@@ -187,6 +180,8 @@ void add_moddevtable(struct buffer *buf, struct module *mod);
 void get_src_version(const char *modname, char sum[], unsigned sumlen);
 
 /* from modpost.c */
+extern bool target_is_big_endian;
+extern bool host_is_big_endian;
 char *read_text_file(const char *filename);
 char *get_line(char **stringp);
 void *sym_get_data(const struct elf_info *info, const Elf_Sym *sym);
-- 
2.43.0

[PATCH 3/4] kbuild: slim down package for building external modules

[Masahiro Yamada]

Exclude directories and files unnecessary for building external modules:

 - include/config/  (except include/config/auto.conf)
 - scripts/atomic/
 - scripts/dtc/
 - scripts/kconfig/
 - scripts/mod/mk_elfconfig
 - scripts/package/
 - scripts/unifdef
 - .config
 - *.o
 - .*.cmd

Avoid copying files twice for the following directories:

 - include/generated/
 - arch/*/include/generated/

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---

 scripts/package/install-extmod-build | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
index 8cc9e13403ae..cc335945dfbc 100755
--- a/scripts/package/install-extmod-build
+++ b/scripts/package/install-extmod-build
@@ -9,15 +9,22 @@ is_enabled() {
 	grep -q "^$1=y" include/config/auto.conf
 }
 
+find_in_scripts() {
+	find scripts \
+		\( -name atomic -o -name dtc -o -name kconfig -o -name package \) -prune -o \
+		! -name unifdef -a ! -name mk_elfconfig -a \( -type f -o -type l \) -print
+}
+
 mkdir -p "${destdir}"
 
 (
 	cd "${srctree}"
 	echo Makefile
 	find "arch/${SRCARCH}" -maxdepth 1 -name 'Makefile*'
-	find include scripts -type f -o -type l
+	find "arch/${SRCARCH}" -name generated -prune -o -name include -type d -print
 	find "arch/${SRCARCH}" -name Kbuild.platforms -o -name Platform
-	find "arch/${SRCARCH}" -name include -type d
+	find include \( -name config -o -name generated \) -prune -o \( -type f -o -type l \) -print
+	find_in_scripts
 ) | tar -c -f - -C "${srctree}" -T - | tar -xf - -C "${destdir}"
 
 {
@@ -25,12 +32,15 @@ mkdir -p "${destdir}"
 		echo tools/objtool/objtool
 	fi
 
-	find "arch/${SRCARCH}/include" Module.symvers include scripts -type f
+	echo Module.symvers
+	echo "arch/${SRCARCH}/include/generated"
+	echo include/config/auto.conf
+	echo include/generated
+	find_in_scripts
 
 	if is_enabled CONFIG_GCC_PLUGINS; then
 		find scripts/gcc-plugins -name '*.so'
 	fi
 } | tar -c -f - -T - | tar -xf - -C "${destdir}"
 
-# copy .config manually to be where it's expected to be
-cp "${KCONFIG_CONFIG}" "${destdir}/.config"
+find "${destdir}" \( -name '.*.cmd' -o -name '*.o' \) -delete
-- 
2.43.0

[PATCH 4/4] kbuild: cross-compile linux-headers package when possible

[Masahiro Yamada]

A long standing issue in the upstream kernel packaging is that the
linux-headers package is not cross-compiled.

For example, you can cross-build Debian packages for arm64 by running
the following command:

  $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg

However, the generated linux-headers-*_arm64.deb is useless because the
host programs in it were built for your build machine architecture
(likely x86), not arm64.

The Debian kernel maintains its own Makefiles to cross-compile host
tools without relying on Kbuild. [1]

Instead of adding such full custom Makefiles, this commit adds a small
piece of code to cross-compile host programs located under the scripts/
directory.

A straightforward solution is to pass HOSTCC=${CROSS_COMPILE}gcc, but it
would also cross-compile scripts/basic/fixdep, which needs to be native
to process the if_changed_dep macro. (This approach may work under some
circumstances; you can execute foreign architecture programs with the
help of binfmt_misc because Debian systems enable CONFIG_BINFMT_MISC,
but it would require installing QEMU and libc for that architecture.)

A trick is to use the external module build (KBUILD_EXTMOD=), which
does not rebuild scripts/basic/fixdep. ${CC} needs to be able to link
userspace programs (CONFIG_CC_CAN_LINK=y).

There are known limitations:

 - GCC plugins

   It would possible to rebuild GCC plugins for the target architecture
   by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
   installed, but gcc on the installed system emits
   "cc1: error: incompatible gcc/plugin versions". I did not find a
   solution for this because 'gcc' on a foreign architecture is a
   different compiler after all.

 - objtool and resolve_btfids

   These are built by the tools build system. They are not covered by
   the current solution.

I only tested this with Debian, but it should work for other package
systems as well.

[1]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/rules.real#L586

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---

 scripts/package/install-extmod-build | 34 ++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
index cc335945dfbc..0b56d3d7b48f 100755
--- a/scripts/package/install-extmod-build
+++ b/scripts/package/install-extmod-build
@@ -43,4 +43,38 @@ mkdir -p "${destdir}"
 	fi
 } | tar -c -f - -T - | tar -xf - -C "${destdir}"
 
+# When ${CC} and ${HOSTCC} differ, we are likely cross-compiling. Rebuild host
+# programs using ${CC}. This assumes CC=${CROSS_COMPILE}gcc, which is usually
+# the case for package building. It does not cross-compile when CC=clang.
+#
+# This caters to host programs that participate in Kbuild. objtool and
+# resolve_btfids are out of scope.
+if [ "${CC}" != "${HOSTCC}" ] && is_enabled CONFIG_CC_CAN_LINK; then
+	echo "Rebuilding host programs with ${CC}..."
+
+	cat <<-'EOF' >  "${destdir}/Kbuild"
+	subdir-y := scripts
+	EOF
+
+	# HOSTCXX is not overridden. The C++ compiler is used to build:
+	# - scripts/kconfig/qconf, which is unneeded for external module builds
+	# - GCC plugins, which will not work on the installed system even with
+	#   being rebuilt.
+	#
+	# Use the single-target build to avoid the modpost invocation, which
+	# would overwrite Module.symvers.
+	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
+
+	cat <<-'EOF' >  "${destdir}/scripts/Kbuild"
+	subdir-y := basic
+	hostprogs-always-y := mod/modpost
+	mod/modpost-objs := $(addprefix mod/, modpost.o file2alias.o sumversion.o symsearch.o)
+	EOF
+
+	# Run once again to rebuild scripts/basic/ and scripts/mod/modpost.
+	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
+
+	rm -f "${destdir}/Kbuild" "${destdir}/scripts/Kbuild"
+fi
+
 find "${destdir}" \( -name '.*.cmd' -o -name '*.o' \) -delete
-- 
2.43.0

Re: [PATCH 4/4] kbuild: cross-compile linux-headers package when possible

[Kees Cook]

On Sat, Jul 27, 2024 at 04:42:04PM +0900, Masahiro Yamada wrote:
> There are known limitations:
> 
>  - GCC plugins
> 
>    It would possible to rebuild GCC plugins for the target architecture
>    by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
>    installed, but gcc on the installed system emits
>    "cc1: error: incompatible gcc/plugin versions". I did not find a
>    solution for this because 'gcc' on a foreign architecture is a
>    different compiler after all.

Do you mean having a plugins as part of a distro package? Does anyone do
this?

-- 
Kees Cook

Re: [PATCH 1/4] modpost: remove unused HOST_ELFCLASS

[Nicolas Schier]

On Sat, Jul 27, 2024 at 04:42:01PM +0900, Masahiro Yamada wrote:
> HOST_ELFCLASS is output to elfconfig.h, but it is not used in modpost.
> 
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
> 
>  scripts/mod/mk_elfconfig.c | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/scripts/mod/mk_elfconfig.c b/scripts/mod/mk_elfconfig.c
> index 680eade89be1..aca96b3aada0 100644
> --- a/scripts/mod/mk_elfconfig.c
> +++ b/scripts/mod/mk_elfconfig.c
> @@ -39,12 +39,6 @@ main(int argc, char **argv)
>  		exit(1);
>  	}
>  
> -	if (sizeof(unsigned long) == 4) {
> -		printf("#define HOST_ELFCLASS ELFCLASS32\n");
> -	} else if (sizeof(unsigned long) == 8) {
> -		printf("#define HOST_ELFCLASS ELFCLASS64\n");
> -	}
> -
>  	endian_test.s = 0x0102;
>  	if (memcmp(endian_test.c, "\x01\x02", 2) == 0)
>  		printf("#define HOST_ELFDATA ELFDATA2MSB\n");
> -- 
> 2.43.0
> 
> 

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

Re: [PATCH 2/4] modpost: detect endianness on run-time

[Nicolas Schier]

On Sat, Jul 27, 2024 at 04:42:02PM +0900, Masahiro Yamada wrote:
> Endianness is currently detected on compile-time, but we can defer this
> until run-time. This change avoids re-executing scripts/mod/mk_elfconfig
> even if modpost in the linux-headers package needs to be rebuilt for a
> foreign architecture.
> 
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---

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

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Nicolas Schier]

On Sat, Jul 27, 2024 at 04:42:03PM +0900, Masahiro Yamada wrote:
> Exclude directories and files unnecessary for building external modules:
> 
>  - include/config/  (except include/config/auto.conf)
>  - scripts/atomic/
>  - scripts/dtc/
>  - scripts/kconfig/
>  - scripts/mod/mk_elfconfig
>  - scripts/package/
>  - scripts/unifdef
>  - .config
>  - *.o
>  - .*.cmd
> 
> Avoid copying files twice for the following directories:
> 
>  - include/generated/
>  - arch/*/include/generated/
> 
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---

nice.

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

Re: [PATCH 4/4] kbuild: cross-compile linux-headers package when possible

[Nicolas Schier]

On Sat, Jul 27, 2024 at 04:42:04PM +0900, Masahiro Yamada wrote:
> A long standing issue in the upstream kernel packaging is that the
> linux-headers package is not cross-compiled.
> 
> For example, you can cross-build Debian packages for arm64 by running
> the following command:
> 
>   $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg
> 
> However, the generated linux-headers-*_arm64.deb is useless because the
> host programs in it were built for your build machine architecture
> (likely x86), not arm64.
> 
> The Debian kernel maintains its own Makefiles to cross-compile host
> tools without relying on Kbuild. [1]
> 
> Instead of adding such full custom Makefiles, this commit adds a small
> piece of code to cross-compile host programs located under the scripts/
> directory.
> 
> A straightforward solution is to pass HOSTCC=${CROSS_COMPILE}gcc, but it
> would also cross-compile scripts/basic/fixdep, which needs to be native
> to process the if_changed_dep macro. (This approach may work under some
> circumstances; you can execute foreign architecture programs with the
> help of binfmt_misc because Debian systems enable CONFIG_BINFMT_MISC,
> but it would require installing QEMU and libc for that architecture.)
> 
> A trick is to use the external module build (KBUILD_EXTMOD=), which
> does not rebuild scripts/basic/fixdep. ${CC} needs to be able to link
> userspace programs (CONFIG_CC_CAN_LINK=y).
> 
> There are known limitations:
> 
>  - GCC plugins
> 
>    It would possible to rebuild GCC plugins for the target architecture
>    by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
>    installed, but gcc on the installed system emits
>    "cc1: error: incompatible gcc/plugin versions". I did not find a
>    solution for this because 'gcc' on a foreign architecture is a
>    different compiler after all.
> 
>  - objtool and resolve_btfids
> 
>    These are built by the tools build system. They are not covered by
>    the current solution.
> 
> I only tested this with Debian, but it should work for other package
> systems as well.
> 
> [1]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/rules.real#L586
> 
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
> 
>  scripts/package/install-extmod-build | 34 ++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> index cc335945dfbc..0b56d3d7b48f 100755
> --- a/scripts/package/install-extmod-build
> +++ b/scripts/package/install-extmod-build
> @@ -43,4 +43,38 @@ mkdir -p "${destdir}"
>  	fi
>  } | tar -c -f - -T - | tar -xf - -C "${destdir}"
>  
> +# When ${CC} and ${HOSTCC} differ, we are likely cross-compiling. Rebuild host
> +# programs using ${CC}. This assumes CC=${CROSS_COMPILE}gcc, which is usually
> +# the case for package building. It does not cross-compile when CC=clang.
> +#
> +# This caters to host programs that participate in Kbuild. objtool and
> +# resolve_btfids are out of scope.

Just for clarification: Why do you call both "out of scope" here?
Because they're not being built by kbuild, or because they will never be
needed for building oot kmods?

> +if [ "${CC}" != "${HOSTCC}" ] && is_enabled CONFIG_CC_CAN_LINK; then
> +	echo "Rebuilding host programs with ${CC}..."
> +
> +	cat <<-'EOF' >  "${destdir}/Kbuild"
> +	subdir-y := scripts
> +	EOF
> +
> +	# HOSTCXX is not overridden. The C++ compiler is used to build:
> +	# - scripts/kconfig/qconf, which is unneeded for external module builds
> +	# - GCC plugins, which will not work on the installed system even with
> +	#   being rebuilt.
> +	#
> +	# Use the single-target build to avoid the modpost invocation, which
> +	# would overwrite Module.symvers.
> +	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> +
> +	cat <<-'EOF' >  "${destdir}/scripts/Kbuild"
> +	subdir-y := basic
> +	hostprogs-always-y := mod/modpost
> +	mod/modpost-objs := $(addprefix mod/, modpost.o file2alias.o sumversion.o symsearch.o)
> +	EOF
> +
> +	# Run once again to rebuild scripts/basic/ and scripts/mod/modpost.
> +	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> +
> +	rm -f "${destdir}/Kbuild" "${destdir}/scripts/Kbuild"
> +fi
> +
>  find "${destdir}" \( -name '.*.cmd' -o -name '*.o' \) -delete
> -- 
> 2.43.0
> 
> 

Thanks for fixing this; looks good to me.

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

Re: [PATCH 4/4] kbuild: cross-compile linux-headers package when possible

[Masahiro Yamada]

On Tue, Jul 30, 2024 at 10:03 AM Kees Cook <kees@kernel.org> wrote:
>
> On Sat, Jul 27, 2024 at 04:42:04PM +0900, Masahiro Yamada wrote:
> > There are known limitations:
> >
> >  - GCC plugins
> >
> >    It would possible to rebuild GCC plugins for the target architecture
> >    by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
> >    installed, but gcc on the installed system emits
> >    "cc1: error: incompatible gcc/plugin versions". I did not find a
> >    solution for this because 'gcc' on a foreign architecture is a
> >    different compiler after all.
>
> Do you mean having a plugins as part of a distro package? Does anyone do
> this?


I think the use of GCC plugins is not so common in distributions,
presumably due to its strong limitation.

In my quick research,
Debian, Ubuntu, Fedora disable CONFIG_GCC_PLUGINS.
Arch Linux enables CONFIG_GCC_PLUGINS.







> --
> Kees Cook
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 4/4] kbuild: cross-compile linux-headers package when possible

[Masahiro Yamada]

On Thu, Aug 1, 2024 at 6:10 AM Nicolas Schier <nicolas@fjasle.eu> wrote:
>
> On Sat, Jul 27, 2024 at 04:42:04PM +0900, Masahiro Yamada wrote:
> > A long standing issue in the upstream kernel packaging is that the
> > linux-headers package is not cross-compiled.
> >
> > For example, you can cross-build Debian packages for arm64 by running
> > the following command:
> >
> >   $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg
> >
> > However, the generated linux-headers-*_arm64.deb is useless because the
> > host programs in it were built for your build machine architecture
> > (likely x86), not arm64.
> >
> > The Debian kernel maintains its own Makefiles to cross-compile host
> > tools without relying on Kbuild. [1]
> >
> > Instead of adding such full custom Makefiles, this commit adds a small
> > piece of code to cross-compile host programs located under the scripts/
> > directory.
> >
> > A straightforward solution is to pass HOSTCC=${CROSS_COMPILE}gcc, but it
> > would also cross-compile scripts/basic/fixdep, which needs to be native
> > to process the if_changed_dep macro. (This approach may work under some
> > circumstances; you can execute foreign architecture programs with the
> > help of binfmt_misc because Debian systems enable CONFIG_BINFMT_MISC,
> > but it would require installing QEMU and libc for that architecture.)
> >
> > A trick is to use the external module build (KBUILD_EXTMOD=), which
> > does not rebuild scripts/basic/fixdep. ${CC} needs to be able to link
> > userspace programs (CONFIG_CC_CAN_LINK=y).
> >
> > There are known limitations:
> >
> >  - GCC plugins
> >
> >    It would possible to rebuild GCC plugins for the target architecture
> >    by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
> >    installed, but gcc on the installed system emits
> >    "cc1: error: incompatible gcc/plugin versions". I did not find a
> >    solution for this because 'gcc' on a foreign architecture is a
> >    different compiler after all.
> >
> >  - objtool and resolve_btfids
> >
> >    These are built by the tools build system. They are not covered by
> >    the current solution.
> >
> > I only tested this with Debian, but it should work for other package
> > systems as well.
> >
> > [1]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/rules.real#L586
> >
> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > ---
> >
> >  scripts/package/install-extmod-build | 34 ++++++++++++++++++++++++++++
> >  1 file changed, 34 insertions(+)
> >
> > diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> > index cc335945dfbc..0b56d3d7b48f 100755
> > --- a/scripts/package/install-extmod-build
> > +++ b/scripts/package/install-extmod-build
> > @@ -43,4 +43,38 @@ mkdir -p "${destdir}"
> >       fi
> >  } | tar -c -f - -T - | tar -xf - -C "${destdir}"
> >
> > +# When ${CC} and ${HOSTCC} differ, we are likely cross-compiling. Rebuild host
> > +# programs using ${CC}. This assumes CC=${CROSS_COMPILE}gcc, which is usually
> > +# the case for package building. It does not cross-compile when CC=clang.
> > +#
> > +# This caters to host programs that participate in Kbuild. objtool and
> > +# resolve_btfids are out of scope.
>
> Just for clarification: Why do you call both "out of scope" here?
> Because they're not being built by kbuild, or because they will never be
> needed for building oot kmods?


I meant the former.


Debian applies a tricky patch to the tools build system
in order to cross-compile objtool:

https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/patches/debian/fixdep-allow-overriding-hostcc-and-hostld.patch

It is not an elegant solution, though.


I still believe the right thing to do is
converting Makefiles for objtool and resolve_btfids into Kbuild style.


objtool and resolve_btfids are necessary for building external modules,
when CONFIG_OBJTOOL=y and CONFIG_DEBUG_INFO_BTF=y, respectively.
If these comments are confusing, I can delete them.







>
> > +if [ "${CC}" != "${HOSTCC}" ] && is_enabled CONFIG_CC_CAN_LINK; then
> > +     echo "Rebuilding host programs with ${CC}..."
> > +
> > +     cat <<-'EOF' >  "${destdir}/Kbuild"
> > +     subdir-y := scripts
> > +     EOF
> > +
> > +     # HOSTCXX is not overridden. The C++ compiler is used to build:
> > +     # - scripts/kconfig/qconf, which is unneeded for external module builds
> > +     # - GCC plugins, which will not work on the installed system even with
> > +     #   being rebuilt.
> > +     #
> > +     # Use the single-target build to avoid the modpost invocation, which
> > +     # would overwrite Module.symvers.
> > +     "${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> > +
> > +     cat <<-'EOF' >  "${destdir}/scripts/Kbuild"
> > +     subdir-y := basic
> > +     hostprogs-always-y := mod/modpost
> > +     mod/modpost-objs := $(addprefix mod/, modpost.o file2alias.o sumversion.o symsearch.o)
> > +     EOF
> > +
> > +     # Run once again to rebuild scripts/basic/ and scripts/mod/modpost.
> > +     "${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> > +
> > +     rm -f "${destdir}/Kbuild" "${destdir}/scripts/Kbuild"
> > +fi
> > +
> >  find "${destdir}" \( -name '.*.cmd' -o -name '*.o' \) -delete
> > --
> > 2.43.0
> >
> >
>
> Thanks for fixing this; looks good to me.
>
> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 4/4] kbuild: cross-compile linux-headers package when possible

[Nicolas Schier]

On Thu, Aug 01, 2024 at 11:37:30AM +0900, Masahiro Yamada wrote:
> On Thu, Aug 1, 2024 at 6:10 AM Nicolas Schier <nicolas@fjasle.eu> wrote:
> >
> > On Sat, Jul 27, 2024 at 04:42:04PM +0900, Masahiro Yamada wrote:
> > > A long standing issue in the upstream kernel packaging is that the
> > > linux-headers package is not cross-compiled.
> > >
> > > For example, you can cross-build Debian packages for arm64 by running
> > > the following command:
> > >
> > >   $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg
> > >
> > > However, the generated linux-headers-*_arm64.deb is useless because the
> > > host programs in it were built for your build machine architecture
> > > (likely x86), not arm64.
> > >
> > > The Debian kernel maintains its own Makefiles to cross-compile host
> > > tools without relying on Kbuild. [1]
> > >
> > > Instead of adding such full custom Makefiles, this commit adds a small
> > > piece of code to cross-compile host programs located under the scripts/
> > > directory.
> > >
> > > A straightforward solution is to pass HOSTCC=${CROSS_COMPILE}gcc, but it
> > > would also cross-compile scripts/basic/fixdep, which needs to be native
> > > to process the if_changed_dep macro. (This approach may work under some
> > > circumstances; you can execute foreign architecture programs with the
> > > help of binfmt_misc because Debian systems enable CONFIG_BINFMT_MISC,
> > > but it would require installing QEMU and libc for that architecture.)
> > >
> > > A trick is to use the external module build (KBUILD_EXTMOD=), which
> > > does not rebuild scripts/basic/fixdep. ${CC} needs to be able to link
> > > userspace programs (CONFIG_CC_CAN_LINK=y).
> > >
> > > There are known limitations:
> > >
> > >  - GCC plugins
> > >
> > >    It would possible to rebuild GCC plugins for the target architecture
> > >    by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
> > >    installed, but gcc on the installed system emits
> > >    "cc1: error: incompatible gcc/plugin versions". I did not find a
> > >    solution for this because 'gcc' on a foreign architecture is a
> > >    different compiler after all.
> > >
> > >  - objtool and resolve_btfids
> > >
> > >    These are built by the tools build system. They are not covered by
> > >    the current solution.
> > >
> > > I only tested this with Debian, but it should work for other package
> > > systems as well.
> > >
> > > [1]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/rules.real#L586
> > >
> > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > > ---
> > >
> > >  scripts/package/install-extmod-build | 34 ++++++++++++++++++++++++++++
> > >  1 file changed, 34 insertions(+)
> > >
> > > diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> > > index cc335945dfbc..0b56d3d7b48f 100755
> > > --- a/scripts/package/install-extmod-build
> > > +++ b/scripts/package/install-extmod-build
> > > @@ -43,4 +43,38 @@ mkdir -p "${destdir}"
> > >       fi
> > >  } | tar -c -f - -T - | tar -xf - -C "${destdir}"
> > >
> > > +# When ${CC} and ${HOSTCC} differ, we are likely cross-compiling. Rebuild host
> > > +# programs using ${CC}. This assumes CC=${CROSS_COMPILE}gcc, which is usually
> > > +# the case for package building. It does not cross-compile when CC=clang.
> > > +#
> > > +# This caters to host programs that participate in Kbuild. objtool and
> > > +# resolve_btfids are out of scope.
> >
> > Just for clarification: Why do you call both "out of scope" here?
> > Because they're not being built by kbuild, or because they will never be
> > needed for building oot kmods?
> 
> 
> I meant the former.
> 
> 
> Debian applies a tricky patch to the tools build system
> in order to cross-compile objtool:
> 
> https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/patches/debian/fixdep-allow-overriding-hostcc-and-hostld.patch
> 
> It is not an elegant solution, though.
> 
> 
> I still believe the right thing to do is
> converting Makefiles for objtool and resolve_btfids into Kbuild style.
> 
> 
> objtool and resolve_btfids are necessary for building external modules,
> when CONFIG_OBJTOOL=y and CONFIG_DEBUG_INFO_BTF=y, respectively.
> If these comments are confusing, I can delete them.

I think it's good to mention that cross-built linux-headers package is
still broken for CONFIG_OBJTOOL=y and CONFIG_DEBUG_INFO_BTF=y.  I think
I'd add a sentence to the commit message and keep the comment here as it
is.

Kind regards,
Nicolas

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Thomas Weißschuh]

Hi Masahiro,

On 2024-07-27 16:42:03+0000, Masahiro Yamada wrote:
> Exclude directories and files unnecessary for building external modules:
> 
>  - include/config/  (except include/config/auto.conf)
>  - scripts/atomic/
>  - scripts/dtc/
>  - scripts/kconfig/
>  - scripts/mod/mk_elfconfig
>  - scripts/package/
>  - scripts/unifdef
>  - .config
>  - *.o
>  - .*.cmd
> 
> Avoid copying files twice for the following directories:
> 
>  - include/generated/
>  - arch/*/include/generated/
> 
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
> 
>  scripts/package/install-extmod-build | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> index 8cc9e13403ae..cc335945dfbc 100755
> --- a/scripts/package/install-extmod-build
> +++ b/scripts/package/install-extmod-build
> @@ -9,15 +9,22 @@ is_enabled() {
>  	grep -q "^$1=y" include/config/auto.conf
>  }
>  
> +find_in_scripts() {
> +	find scripts \
> +		\( -name atomic -o -name dtc -o -name kconfig -o -name package \) -prune -o \
> +		! -name unifdef -a ! -name mk_elfconfig -a \( -type f -o -type l \) -print
> +}
> +
>  mkdir -p "${destdir}"
>  
>  (
>  	cd "${srctree}"
>  	echo Makefile
>  	find "arch/${SRCARCH}" -maxdepth 1 -name 'Makefile*'
> -	find include scripts -type f -o -type l
> +	find "arch/${SRCARCH}" -name generated -prune -o -name include -type d -print
>  	find "arch/${SRCARCH}" -name Kbuild.platforms -o -name Platform
> -	find "arch/${SRCARCH}" -name include -type d
> +	find include \( -name config -o -name generated \) -prune -o \( -type f -o -type l \) -print
> +	find_in_scripts
>  ) | tar -c -f - -C "${srctree}" -T - | tar -xf - -C "${destdir}"
>  
>  {
> @@ -25,12 +32,15 @@ mkdir -p "${destdir}"
>  		echo tools/objtool/objtool
>  	fi
>  
> -	find "arch/${SRCARCH}/include" Module.symvers include scripts -type f
> +	echo Module.symvers
> +	echo "arch/${SRCARCH}/include/generated"
> +	echo include/config/auto.conf
> +	echo include/generated
> +	find_in_scripts

This now excludes include/config/kernel.release which is used to set
KERNELRELEASE, which is commonly used by Makefiles.
See Documentation/kbuild/modules.txt, other users also seem not unlikely.

IMO this specific file should be added back.


Thanks,
Thomas

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Masahiro Yamada]

On Sat, Aug 24, 2024 at 9:27 PM Thomas Weißschuh <thomas@t-8ch.de> wrote:
>
> Hi Masahiro,
>
> On 2024-07-27 16:42:03+0000, Masahiro Yamada wrote:
> > Exclude directories and files unnecessary for building external modules:
> >
> >  - include/config/  (except include/config/auto.conf)
> >  - scripts/atomic/
> >  - scripts/dtc/
> >  - scripts/kconfig/
> >  - scripts/mod/mk_elfconfig
> >  - scripts/package/
> >  - scripts/unifdef
> >  - .config
> >  - *.o
> >  - .*.cmd
> >
> > Avoid copying files twice for the following directories:
> >
> >  - include/generated/
> >  - arch/*/include/generated/
> >
> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > ---
> >
> >  scripts/package/install-extmod-build | 20 +++++++++++++++-----
> >  1 file changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> > index 8cc9e13403ae..cc335945dfbc 100755
> > --- a/scripts/package/install-extmod-build
> > +++ b/scripts/package/install-extmod-build
> > @@ -9,15 +9,22 @@ is_enabled() {
> >       grep -q "^$1=y" include/config/auto.conf
> >  }
> >
> > +find_in_scripts() {
> > +     find scripts \
> > +             \( -name atomic -o -name dtc -o -name kconfig -o -name package \) -prune -o \
> > +             ! -name unifdef -a ! -name mk_elfconfig -a \( -type f -o -type l \) -print
> > +}
> > +
> >  mkdir -p "${destdir}"
> >
> >  (
> >       cd "${srctree}"
> >       echo Makefile
> >       find "arch/${SRCARCH}" -maxdepth 1 -name 'Makefile*'
> > -     find include scripts -type f -o -type l
> > +     find "arch/${SRCARCH}" -name generated -prune -o -name include -type d -print
> >       find "arch/${SRCARCH}" -name Kbuild.platforms -o -name Platform
> > -     find "arch/${SRCARCH}" -name include -type d
> > +     find include \( -name config -o -name generated \) -prune -o \( -type f -o -type l \) -print
> > +     find_in_scripts
> >  ) | tar -c -f - -C "${srctree}" -T - | tar -xf - -C "${destdir}"
> >
> >  {
> > @@ -25,12 +32,15 @@ mkdir -p "${destdir}"
> >               echo tools/objtool/objtool
> >       fi
> >
> > -     find "arch/${SRCARCH}/include" Module.symvers include scripts -type f
> > +     echo Module.symvers
> > +     echo "arch/${SRCARCH}/include/generated"
> > +     echo include/config/auto.conf
> > +     echo include/generated
> > +     find_in_scripts
>
> This now excludes include/config/kernel.release which is used to set
> KERNELRELEASE, which is commonly used by Makefiles.
> See Documentation/kbuild/modules.txt, other users also seem not unlikely.
>
> IMO this specific file should be added back.


Agree.

I fixed it up locally. Thanks for the report.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH 4/4] kbuild: cross-compile linux-headers package when possible

[Ron Economos]

On 7/27/24 12:42 AM, Masahiro Yamada wrote:
> A long standing issue in the upstream kernel packaging is that the
> linux-headers package is not cross-compiled.
>
> For example, you can cross-build Debian packages for arm64 by running
> the following command:
>
>    $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg
>
> However, the generated linux-headers-*_arm64.deb is useless because the
> host programs in it were built for your build machine architecture
> (likely x86), not arm64.
>
> The Debian kernel maintains its own Makefiles to cross-compile host
> tools without relying on Kbuild. [1]
>
> Instead of adding such full custom Makefiles, this commit adds a small
> piece of code to cross-compile host programs located under the scripts/
> directory.
>
> A straightforward solution is to pass HOSTCC=${CROSS_COMPILE}gcc, but it
> would also cross-compile scripts/basic/fixdep, which needs to be native
> to process the if_changed_dep macro. (This approach may work under some
> circumstances; you can execute foreign architecture programs with the
> help of binfmt_misc because Debian systems enable CONFIG_BINFMT_MISC,
> but it would require installing QEMU and libc for that architecture.)
>
> A trick is to use the external module build (KBUILD_EXTMOD=), which
> does not rebuild scripts/basic/fixdep. ${CC} needs to be able to link
> userspace programs (CONFIG_CC_CAN_LINK=y).
>
> There are known limitations:
>
>   - GCC plugins
>
>     It would possible to rebuild GCC plugins for the target architecture
>     by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
>     installed, but gcc on the installed system emits
>     "cc1: error: incompatible gcc/plugin versions". I did not find a
>     solution for this because 'gcc' on a foreign architecture is a
>     different compiler after all.
>
>   - objtool and resolve_btfids
>
>     These are built by the tools build system. They are not covered by
>     the current solution.
>
> I only tested this with Debian, but it should work for other package
> systems as well.
>
> [1]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/rules.real#L586
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
>
>   scripts/package/install-extmod-build | 34 ++++++++++++++++++++++++++++
>   1 file changed, 34 insertions(+)
>
> diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> index cc335945dfbc..0b56d3d7b48f 100755
> --- a/scripts/package/install-extmod-build
> +++ b/scripts/package/install-extmod-build
> @@ -43,4 +43,38 @@ mkdir -p "${destdir}"
>   	fi
>   } | tar -c -f - -T - | tar -xf - -C "${destdir}"
>   
> +# When ${CC} and ${HOSTCC} differ, we are likely cross-compiling. Rebuild host
> +# programs using ${CC}. This assumes CC=${CROSS_COMPILE}gcc, which is usually
> +# the case for package building. It does not cross-compile when CC=clang.
> +#
> +# This caters to host programs that participate in Kbuild. objtool and
> +# resolve_btfids are out of scope.
> +if [ "${CC}" != "${HOSTCC}" ] && is_enabled CONFIG_CC_CAN_LINK; then
> +	echo "Rebuilding host programs with ${CC}..."
> +
> +	cat <<-'EOF' >  "${destdir}/Kbuild"
> +	subdir-y := scripts
> +	EOF
> +
> +	# HOSTCXX is not overridden. The C++ compiler is used to build:
> +	# - scripts/kconfig/qconf, which is unneeded for external module builds
> +	# - GCC plugins, which will not work on the installed system even with
> +	#   being rebuilt.
> +	#
> +	# Use the single-target build to avoid the modpost invocation, which
> +	# would overwrite Module.symvers.
> +	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> +
> +	cat <<-'EOF' >  "${destdir}/scripts/Kbuild"
> +	subdir-y := basic
> +	hostprogs-always-y := mod/modpost
> +	mod/modpost-objs := $(addprefix mod/, modpost.o file2alias.o sumversion.o symsearch.o)
> +	EOF
> +
> +	# Run once again to rebuild scripts/basic/ and scripts/mod/modpost.
> +	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> +
> +	rm -f "${destdir}/Kbuild" "${destdir}/scripts/Kbuild"
> +fi
> +
>   find "${destdir}" \( -name '.*.cmd' -o -name '*.o' \) -delete

This patch causes a build error when cross-compiling for RISC-V. I'm 
using the cross-compiler from 
https://github.com/riscv-collab/riscv-gnu-toolchain. When trying to 
build .debs with:

make CROSS_COMPILE=riscv64-unknown-linux-gnu- ARCH=riscv 
INSTALL_MOD_STRIP=1 "KCFLAGS=-mtune=sifive-7-series" LOCALVERSION= 
bindeb-pkg

I get the following error:

Rebuilding host programs with riscv64-unknown-linux-gnu-gcc...
   HOSTCC 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/genksyms.o
   YACC 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/parse.tab.[ch]
   HOSTCC 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/parse.tab.o
   LEX 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/lex.lex.c
   HOSTCC 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/lex.lex.o
   HOSTLD 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/genksyms
   HOSTCC 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/selinux/genheaders/genheaders
   HOSTCC 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/selinux/mdp/mdp
   HOSTCC 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/kallsyms
   HOSTCC 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sorttable
   HOSTCC 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/asn1_compiler
   HOSTCC 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sign-file

debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sign-file.c:25:10: 
fatal error: openssl/opensslv.h: No such file or directory
    25 | #include <openssl/opensslv.h>
       |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[7]: *** [scripts/Makefile.host:116: 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sign-file] 
Error 1
make[6]: *** [scripts/Makefile.build:478: 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts] 
Error 2
make[5]: *** [Makefile:1936: 
debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3] Error 2
make[4]: *** [Makefile:2063: run-command] Error 2
make[3]: *** [debian/rules:61: binary-headers] Error 2
dpkg-buildpackage: error: make -f debian/rules binary subprocess 
returned exit status 2
make[2]: *** [scripts/Makefile.package:121: bindeb-pkg] Error 2
make[1]: *** [/home/re/xfer/linux/Makefile:1557: bindeb-pkg] Error 2
make: *** [Makefile:224: __sub-make] Error 2

Re: [PATCH 4/4] kbuild: cross-compile linux-headers package when possible

[Nicolas Schier]

On Thu, Oct 17, 2024 at 07:45:57AM -0700 Ron Economos wrote:
> On 7/27/24 12:42 AM, Masahiro Yamada wrote:
> > A long standing issue in the upstream kernel packaging is that the
> > linux-headers package is not cross-compiled.
> > 
> > For example, you can cross-build Debian packages for arm64 by running
> > the following command:
> > 
> >    $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg
> > 
> > However, the generated linux-headers-*_arm64.deb is useless because the
> > host programs in it were built for your build machine architecture
> > (likely x86), not arm64.
> > 
> > The Debian kernel maintains its own Makefiles to cross-compile host
> > tools without relying on Kbuild. [1]
> > 
> > Instead of adding such full custom Makefiles, this commit adds a small
> > piece of code to cross-compile host programs located under the scripts/
> > directory.
> > 
> > A straightforward solution is to pass HOSTCC=${CROSS_COMPILE}gcc, but it
> > would also cross-compile scripts/basic/fixdep, which needs to be native
> > to process the if_changed_dep macro. (This approach may work under some
> > circumstances; you can execute foreign architecture programs with the
> > help of binfmt_misc because Debian systems enable CONFIG_BINFMT_MISC,
> > but it would require installing QEMU and libc for that architecture.)
> > 
> > A trick is to use the external module build (KBUILD_EXTMOD=), which
> > does not rebuild scripts/basic/fixdep. ${CC} needs to be able to link
> > userspace programs (CONFIG_CC_CAN_LINK=y).
> > 
> > There are known limitations:
> > 
> >   - GCC plugins
> > 
> >     It would possible to rebuild GCC plugins for the target architecture
> >     by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
> >     installed, but gcc on the installed system emits
> >     "cc1: error: incompatible gcc/plugin versions". I did not find a
> >     solution for this because 'gcc' on a foreign architecture is a
> >     different compiler after all.
> > 
> >   - objtool and resolve_btfids
> > 
> >     These are built by the tools build system. They are not covered by
> >     the current solution.
> > 
> > I only tested this with Debian, but it should work for other package
> > systems as well.
> > 
> > [1]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/rules.real#L586
> > 
> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > ---
> > 
> >   scripts/package/install-extmod-build | 34 ++++++++++++++++++++++++++++
> >   1 file changed, 34 insertions(+)
> > 
> > diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> > index cc335945dfbc..0b56d3d7b48f 100755
> > --- a/scripts/package/install-extmod-build
> > +++ b/scripts/package/install-extmod-build
> > @@ -43,4 +43,38 @@ mkdir -p "${destdir}"
> >   	fi
> >   } | tar -c -f - -T - | tar -xf - -C "${destdir}"
> > +# When ${CC} and ${HOSTCC} differ, we are likely cross-compiling. Rebuild host
> > +# programs using ${CC}. This assumes CC=${CROSS_COMPILE}gcc, which is usually
> > +# the case for package building. It does not cross-compile when CC=clang.
> > +#
> > +# This caters to host programs that participate in Kbuild. objtool and
> > +# resolve_btfids are out of scope.
> > +if [ "${CC}" != "${HOSTCC}" ] && is_enabled CONFIG_CC_CAN_LINK; then
> > +	echo "Rebuilding host programs with ${CC}..."
> > +
> > +	cat <<-'EOF' >  "${destdir}/Kbuild"
> > +	subdir-y := scripts
> > +	EOF
> > +
> > +	# HOSTCXX is not overridden. The C++ compiler is used to build:
> > +	# - scripts/kconfig/qconf, which is unneeded for external module builds
> > +	# - GCC plugins, which will not work on the installed system even with
> > +	#   being rebuilt.
> > +	#
> > +	# Use the single-target build to avoid the modpost invocation, which
> > +	# would overwrite Module.symvers.
> > +	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> > +
> > +	cat <<-'EOF' >  "${destdir}/scripts/Kbuild"
> > +	subdir-y := basic
> > +	hostprogs-always-y := mod/modpost
> > +	mod/modpost-objs := $(addprefix mod/, modpost.o file2alias.o sumversion.o symsearch.o)
> > +	EOF
> > +
> > +	# Run once again to rebuild scripts/basic/ and scripts/mod/modpost.
> > +	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> > +
> > +	rm -f "${destdir}/Kbuild" "${destdir}/scripts/Kbuild"
> > +fi
> > +
> >   find "${destdir}" \( -name '.*.cmd' -o -name '*.o' \) -delete
> 
> This patch causes a build error when cross-compiling for RISC-V. I'm using
> the cross-compiler from https://github.com/riscv-collab/riscv-gnu-toolchain.
> When trying to build .debs with:
> 
> make CROSS_COMPILE=riscv64-unknown-linux-gnu- ARCH=riscv INSTALL_MOD_STRIP=1
> "KCFLAGS=-mtune=sifive-7-series" LOCALVERSION= bindeb-pkg
> 
> I get the following error:
> 
> Rebuilding host programs with riscv64-unknown-linux-gnu-gcc...
>   HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/genksyms.o
>   YACC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/parse.tab.[ch]
>   HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/parse.tab.o
>   LEX debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/lex.lex.c
>   HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/lex.lex.o
>   HOSTLD debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/genksyms
>   HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/selinux/genheaders/genheaders
>   HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/selinux/mdp/mdp
>   HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/kallsyms
>   HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sorttable
>   HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/asn1_compiler
>   HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sign-file
> 
> debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sign-file.c:25:10:
> fatal error: openssl/opensslv.h: No such file or directory
>    25 | #include <openssl/opensslv.h>
>       |          ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.

I guess you have openssl/opensslv.h available on your system, do you?  (In
Debian/Ubuntu package libssl-dev or similar)

Can you natively build a kernel with a similar kernel config?

Kind regards,
Nicolas

Re: [PATCH 4/4] kbuild: cross-compile linux-headers package when possible

[Ron Economos]

On 10/17/24 12:24 PM, Nicolas Schier wrote:
> On Thu, Oct 17, 2024 at 07:45:57AM -0700 Ron Economos wrote:
>> On 7/27/24 12:42 AM, Masahiro Yamada wrote:
>>> A long standing issue in the upstream kernel packaging is that the
>>> linux-headers package is not cross-compiled.
>>>
>>> For example, you can cross-build Debian packages for arm64 by running
>>> the following command:
>>>
>>>     $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg
>>>
>>> However, the generated linux-headers-*_arm64.deb is useless because the
>>> host programs in it were built for your build machine architecture
>>> (likely x86), not arm64.
>>>
>>> The Debian kernel maintains its own Makefiles to cross-compile host
>>> tools without relying on Kbuild. [1]
>>>
>>> Instead of adding such full custom Makefiles, this commit adds a small
>>> piece of code to cross-compile host programs located under the scripts/
>>> directory.
>>>
>>> A straightforward solution is to pass HOSTCC=${CROSS_COMPILE}gcc, but it
>>> would also cross-compile scripts/basic/fixdep, which needs to be native
>>> to process the if_changed_dep macro. (This approach may work under some
>>> circumstances; you can execute foreign architecture programs with the
>>> help of binfmt_misc because Debian systems enable CONFIG_BINFMT_MISC,
>>> but it would require installing QEMU and libc for that architecture.)
>>>
>>> A trick is to use the external module build (KBUILD_EXTMOD=), which
>>> does not rebuild scripts/basic/fixdep. ${CC} needs to be able to link
>>> userspace programs (CONFIG_CC_CAN_LINK=y).
>>>
>>> There are known limitations:
>>>
>>>    - GCC plugins
>>>
>>>      It would possible to rebuild GCC plugins for the target architecture
>>>      by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
>>>      installed, but gcc on the installed system emits
>>>      "cc1: error: incompatible gcc/plugin versions". I did not find a
>>>      solution for this because 'gcc' on a foreign architecture is a
>>>      different compiler after all.
>>>
>>>    - objtool and resolve_btfids
>>>
>>>      These are built by the tools build system. They are not covered by
>>>      the current solution.
>>>
>>> I only tested this with Debian, but it should work for other package
>>> systems as well.
>>>
>>> [1]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/rules.real#L586
>>>
>>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
>>> ---
>>>
>>>    scripts/package/install-extmod-build | 34 ++++++++++++++++++++++++++++
>>>    1 file changed, 34 insertions(+)
>>>
>>> diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
>>> index cc335945dfbc..0b56d3d7b48f 100755
>>> --- a/scripts/package/install-extmod-build
>>> +++ b/scripts/package/install-extmod-build
>>> @@ -43,4 +43,38 @@ mkdir -p "${destdir}"
>>>    	fi
>>>    } | tar -c -f - -T - | tar -xf - -C "${destdir}"
>>> +# When ${CC} and ${HOSTCC} differ, we are likely cross-compiling. Rebuild host
>>> +# programs using ${CC}. This assumes CC=${CROSS_COMPILE}gcc, which is usually
>>> +# the case for package building. It does not cross-compile when CC=clang.
>>> +#
>>> +# This caters to host programs that participate in Kbuild. objtool and
>>> +# resolve_btfids are out of scope.
>>> +if [ "${CC}" != "${HOSTCC}" ] && is_enabled CONFIG_CC_CAN_LINK; then
>>> +	echo "Rebuilding host programs with ${CC}..."
>>> +
>>> +	cat <<-'EOF' >  "${destdir}/Kbuild"
>>> +	subdir-y := scripts
>>> +	EOF
>>> +
>>> +	# HOSTCXX is not overridden. The C++ compiler is used to build:
>>> +	# - scripts/kconfig/qconf, which is unneeded for external module builds
>>> +	# - GCC plugins, which will not work on the installed system even with
>>> +	#   being rebuilt.
>>> +	#
>>> +	# Use the single-target build to avoid the modpost invocation, which
>>> +	# would overwrite Module.symvers.
>>> +	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
>>> +
>>> +	cat <<-'EOF' >  "${destdir}/scripts/Kbuild"
>>> +	subdir-y := basic
>>> +	hostprogs-always-y := mod/modpost
>>> +	mod/modpost-objs := $(addprefix mod/, modpost.o file2alias.o sumversion.o symsearch.o)
>>> +	EOF
>>> +
>>> +	# Run once again to rebuild scripts/basic/ and scripts/mod/modpost.
>>> +	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
>>> +
>>> +	rm -f "${destdir}/Kbuild" "${destdir}/scripts/Kbuild"
>>> +fi
>>> +
>>>    find "${destdir}" \( -name '.*.cmd' -o -name '*.o' \) -delete
>> This patch causes a build error when cross-compiling for RISC-V. I'm using
>> the cross-compiler from https://github.com/riscv-collab/riscv-gnu-toolchain.
>> When trying to build .debs with:
>>
>> make CROSS_COMPILE=riscv64-unknown-linux-gnu- ARCH=riscv INSTALL_MOD_STRIP=1
>> "KCFLAGS=-mtune=sifive-7-series" LOCALVERSION= bindeb-pkg
>>
>> I get the following error:
>>
>> Rebuilding host programs with riscv64-unknown-linux-gnu-gcc...
>>    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/genksyms.o
>>    YACC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/parse.tab.[ch]
>>    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/parse.tab.o
>>    LEX debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/lex.lex.c
>>    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/lex.lex.o
>>    HOSTLD debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/genksyms
>>    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/selinux/genheaders/genheaders
>>    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/selinux/mdp/mdp
>>    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/kallsyms
>>    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sorttable
>>    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/asn1_compiler
>>    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sign-file
>>
>> debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sign-file.c:25:10:
>> fatal error: openssl/opensslv.h: No such file or directory
>>     25 | #include <openssl/opensslv.h>
>>        |          ^~~~~~~~~~~~~~~~~~~~
>> compilation terminated.
> I guess you have openssl/opensslv.h available on your system, do you?  (In
> Debian/Ubuntu package libssl-dev or similar)
>
> Can you natively build a kernel with a similar kernel config?
>
> Kind regards,
> Nicolas

Yes, I have /usr/include/openssl/opensslv.h on my system. But that's the 
x86 version. The cross compiler can't use that.

A native build works fine.

Ron

Re: [PATCH 4/4] kbuild: cross-compile linux-headers package when possible

[Charlie Jenkins]

On Thu, Oct 17, 2024 at 12:34:49PM -0700, Ron Economos wrote:
> On 10/17/24 12:24 PM, Nicolas Schier wrote:
> > On Thu, Oct 17, 2024 at 07:45:57AM -0700 Ron Economos wrote:
> > > On 7/27/24 12:42 AM, Masahiro Yamada wrote:
> > > > A long standing issue in the upstream kernel packaging is that the
> > > > linux-headers package is not cross-compiled.
> > > > 
> > > > For example, you can cross-build Debian packages for arm64 by running
> > > > the following command:
> > > > 
> > > >     $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg
> > > > 
> > > > However, the generated linux-headers-*_arm64.deb is useless because the
> > > > host programs in it were built for your build machine architecture
> > > > (likely x86), not arm64.
> > > > 
> > > > The Debian kernel maintains its own Makefiles to cross-compile host
> > > > tools without relying on Kbuild. [1]
> > > > 
> > > > Instead of adding such full custom Makefiles, this commit adds a small
> > > > piece of code to cross-compile host programs located under the scripts/
> > > > directory.
> > > > 
> > > > A straightforward solution is to pass HOSTCC=${CROSS_COMPILE}gcc, but it
> > > > would also cross-compile scripts/basic/fixdep, which needs to be native
> > > > to process the if_changed_dep macro. (This approach may work under some
> > > > circumstances; you can execute foreign architecture programs with the
> > > > help of binfmt_misc because Debian systems enable CONFIG_BINFMT_MISC,
> > > > but it would require installing QEMU and libc for that architecture.)
> > > > 
> > > > A trick is to use the external module build (KBUILD_EXTMOD=), which
> > > > does not rebuild scripts/basic/fixdep. ${CC} needs to be able to link
> > > > userspace programs (CONFIG_CC_CAN_LINK=y).
> > > > 
> > > > There are known limitations:
> > > > 
> > > >    - GCC plugins
> > > > 
> > > >      It would possible to rebuild GCC plugins for the target architecture
> > > >      by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
> > > >      installed, but gcc on the installed system emits
> > > >      "cc1: error: incompatible gcc/plugin versions". I did not find a
> > > >      solution for this because 'gcc' on a foreign architecture is a
> > > >      different compiler after all.
> > > > 
> > > >    - objtool and resolve_btfids
> > > > 
> > > >      These are built by the tools build system. They are not covered by
> > > >      the current solution.
> > > > 
> > > > I only tested this with Debian, but it should work for other package
> > > > systems as well.
> > > > 
> > > > [1]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/rules.real#L586
> > > > 
> > > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > > > ---
> > > > 
> > > >    scripts/package/install-extmod-build | 34 ++++++++++++++++++++++++++++
> > > >    1 file changed, 34 insertions(+)
> > > > 
> > > > diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> > > > index cc335945dfbc..0b56d3d7b48f 100755
> > > > --- a/scripts/package/install-extmod-build
> > > > +++ b/scripts/package/install-extmod-build
> > > > @@ -43,4 +43,38 @@ mkdir -p "${destdir}"
> > > >    	fi
> > > >    } | tar -c -f - -T - | tar -xf - -C "${destdir}"
> > > > +# When ${CC} and ${HOSTCC} differ, we are likely cross-compiling. Rebuild host
> > > > +# programs using ${CC}. This assumes CC=${CROSS_COMPILE}gcc, which is usually
> > > > +# the case for package building. It does not cross-compile when CC=clang.
> > > > +#
> > > > +# This caters to host programs that participate in Kbuild. objtool and
> > > > +# resolve_btfids are out of scope.
> > > > +if [ "${CC}" != "${HOSTCC}" ] && is_enabled CONFIG_CC_CAN_LINK; then
> > > > +	echo "Rebuilding host programs with ${CC}..."
> > > > +
> > > > +	cat <<-'EOF' >  "${destdir}/Kbuild"
> > > > +	subdir-y := scripts
> > > > +	EOF
> > > > +
> > > > +	# HOSTCXX is not overridden. The C++ compiler is used to build:
> > > > +	# - scripts/kconfig/qconf, which is unneeded for external module builds
> > > > +	# - GCC plugins, which will not work on the installed system even with
> > > > +	#   being rebuilt.
> > > > +	#
> > > > +	# Use the single-target build to avoid the modpost invocation, which
> > > > +	# would overwrite Module.symvers.
> > > > +	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> > > > +
> > > > +	cat <<-'EOF' >  "${destdir}/scripts/Kbuild"
> > > > +	subdir-y := basic
> > > > +	hostprogs-always-y := mod/modpost
> > > > +	mod/modpost-objs := $(addprefix mod/, modpost.o file2alias.o sumversion.o symsearch.o)
> > > > +	EOF
> > > > +
> > > > +	# Run once again to rebuild scripts/basic/ and scripts/mod/modpost.
> > > > +	"${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> > > > +
> > > > +	rm -f "${destdir}/Kbuild" "${destdir}/scripts/Kbuild"
> > > > +fi
> > > > +
> > > >    find "${destdir}" \( -name '.*.cmd' -o -name '*.o' \) -delete
> > > This patch causes a build error when cross-compiling for RISC-V. I'm using
> > > the cross-compiler from https://github.com/riscv-collab/riscv-gnu-toolchain.
> > > When trying to build .debs with:
> > > 
> > > make CROSS_COMPILE=riscv64-unknown-linux-gnu- ARCH=riscv INSTALL_MOD_STRIP=1
> > > "KCFLAGS=-mtune=sifive-7-series" LOCALVERSION= bindeb-pkg
> > > 
> > > I get the following error:
> > > 
> > > Rebuilding host programs with riscv64-unknown-linux-gnu-gcc...
> > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/genksyms.o
> > >    YACC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/parse.tab.[ch]
> > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/parse.tab.o
> > >    LEX debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/lex.lex.c
> > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/lex.lex.o
> > >    HOSTLD debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/genksyms
> > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/selinux/genheaders/genheaders
> > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/selinux/mdp/mdp
> > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/kallsyms
> > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sorttable
> > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/asn1_compiler
> > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sign-file
> > > 
> > > debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sign-file.c:25:10:
> > > fatal error: openssl/opensslv.h: No such file or directory
> > >     25 | #include <openssl/opensslv.h>
> > >        |          ^~~~~~~~~~~~~~~~~~~~
> > > compilation terminated.
> > I guess you have openssl/opensslv.h available on your system, do you?  (In
> > Debian/Ubuntu package libssl-dev or similar)
> > 
> > Can you natively build a kernel with a similar kernel config?
> > 
> > Kind regards,
> > Nicolas
> 
> Yes, I have /usr/include/openssl/opensslv.h on my system. But that's the x86
> version. The cross compiler can't use that.

You'll need to add the package for cross-compilation. If you are using
ubuntu and the ubuntu riscv64 toolchain, you can add the riscv64
architecture `dpkg --add-architecture riscv64`, swap out your
sources.list file to specify the architecture `sed -i 's/^deb/deb
[arch=amd64]/' /etc/apt/sources.list`, add the riscv64 debs to your
sources.list:

deb [arch=riscv64] http://ports.ubuntu.com/ubuntu-ports jammy main restricted multiverse universe
deb [arch=riscv64] http://ports.ubuntu.com/ubuntu-ports jammy-updates main
deb [arch=riscv64] http://ports.ubuntu.com/ubuntu-ports jammy-security main

Then `apt update` and `apt install libssl-dev:riscv64`. I imagine there
is a similar procedure for other distros. If using a custom compiler,
you'll need to copy over the installed headers to whatever location your
compiler is looking for them.

- Charlie

> 
> A native build works fine.
> 
> Ron
> 
> 

Re: [PATCH 4/4] kbuild: cross-compile linux-headers package when possible

[Masahiro Yamada]

On Fri, Nov 15, 2024 at 5:57 AM Charlie Jenkins <charlie@rivosinc.com> wrote:
>
> On Thu, Oct 17, 2024 at 12:34:49PM -0700, Ron Economos wrote:
> > On 10/17/24 12:24 PM, Nicolas Schier wrote:
> > > On Thu, Oct 17, 2024 at 07:45:57AM -0700 Ron Economos wrote:
> > > > On 7/27/24 12:42 AM, Masahiro Yamada wrote:
> > > > > A long standing issue in the upstream kernel packaging is that the
> > > > > linux-headers package is not cross-compiled.
> > > > >
> > > > > For example, you can cross-build Debian packages for arm64 by running
> > > > > the following command:
> > > > >
> > > > >     $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg
> > > > >
> > > > > However, the generated linux-headers-*_arm64.deb is useless because the
> > > > > host programs in it were built for your build machine architecture
> > > > > (likely x86), not arm64.
> > > > >
> > > > > The Debian kernel maintains its own Makefiles to cross-compile host
> > > > > tools without relying on Kbuild. [1]
> > > > >
> > > > > Instead of adding such full custom Makefiles, this commit adds a small
> > > > > piece of code to cross-compile host programs located under the scripts/
> > > > > directory.
> > > > >
> > > > > A straightforward solution is to pass HOSTCC=${CROSS_COMPILE}gcc, but it
> > > > > would also cross-compile scripts/basic/fixdep, which needs to be native
> > > > > to process the if_changed_dep macro. (This approach may work under some
> > > > > circumstances; you can execute foreign architecture programs with the
> > > > > help of binfmt_misc because Debian systems enable CONFIG_BINFMT_MISC,
> > > > > but it would require installing QEMU and libc for that architecture.)
> > > > >
> > > > > A trick is to use the external module build (KBUILD_EXTMOD=), which
> > > > > does not rebuild scripts/basic/fixdep. ${CC} needs to be able to link
> > > > > userspace programs (CONFIG_CC_CAN_LINK=y).
> > > > >
> > > > > There are known limitations:
> > > > >
> > > > >    - GCC plugins
> > > > >
> > > > >      It would possible to rebuild GCC plugins for the target architecture
> > > > >      by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
> > > > >      installed, but gcc on the installed system emits
> > > > >      "cc1: error: incompatible gcc/plugin versions". I did not find a
> > > > >      solution for this because 'gcc' on a foreign architecture is a
> > > > >      different compiler after all.
> > > > >
> > > > >    - objtool and resolve_btfids
> > > > >
> > > > >      These are built by the tools build system. They are not covered by
> > > > >      the current solution.
> > > > >
> > > > > I only tested this with Debian, but it should work for other package
> > > > > systems as well.
> > > > >
> > > > > [1]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/rules.real#L586
> > > > >
> > > > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > > > > ---
> > > > >
> > > > >    scripts/package/install-extmod-build | 34 ++++++++++++++++++++++++++++
> > > > >    1 file changed, 34 insertions(+)
> > > > >
> > > > > diff --git a/scripts/package/install-extmod-build b/scripts/package/install-extmod-build
> > > > > index cc335945dfbc..0b56d3d7b48f 100755
> > > > > --- a/scripts/package/install-extmod-build
> > > > > +++ b/scripts/package/install-extmod-build
> > > > > @@ -43,4 +43,38 @@ mkdir -p "${destdir}"
> > > > >         fi
> > > > >    } | tar -c -f - -T - | tar -xf - -C "${destdir}"
> > > > > +# When ${CC} and ${HOSTCC} differ, we are likely cross-compiling. Rebuild host
> > > > > +# programs using ${CC}. This assumes CC=${CROSS_COMPILE}gcc, which is usually
> > > > > +# the case for package building. It does not cross-compile when CC=clang.
> > > > > +#
> > > > > +# This caters to host programs that participate in Kbuild. objtool and
> > > > > +# resolve_btfids are out of scope.
> > > > > +if [ "${CC}" != "${HOSTCC}" ] && is_enabled CONFIG_CC_CAN_LINK; then
> > > > > +       echo "Rebuilding host programs with ${CC}..."
> > > > > +
> > > > > +       cat <<-'EOF' >  "${destdir}/Kbuild"
> > > > > +       subdir-y := scripts
> > > > > +       EOF
> > > > > +
> > > > > +       # HOSTCXX is not overridden. The C++ compiler is used to build:
> > > > > +       # - scripts/kconfig/qconf, which is unneeded for external module builds
> > > > > +       # - GCC plugins, which will not work on the installed system even with
> > > > > +       #   being rebuilt.
> > > > > +       #
> > > > > +       # Use the single-target build to avoid the modpost invocation, which
> > > > > +       # would overwrite Module.symvers.
> > > > > +       "${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> > > > > +
> > > > > +       cat <<-'EOF' >  "${destdir}/scripts/Kbuild"
> > > > > +       subdir-y := basic
> > > > > +       hostprogs-always-y := mod/modpost
> > > > > +       mod/modpost-objs := $(addprefix mod/, modpost.o file2alias.o sumversion.o symsearch.o)
> > > > > +       EOF
> > > > > +
> > > > > +       # Run once again to rebuild scripts/basic/ and scripts/mod/modpost.
> > > > > +       "${MAKE}" HOSTCC="${CC}" KBUILD_EXTMOD="${destdir}" scripts/
> > > > > +
> > > > > +       rm -f "${destdir}/Kbuild" "${destdir}/scripts/Kbuild"
> > > > > +fi
> > > > > +
> > > > >    find "${destdir}" \( -name '.*.cmd' -o -name '*.o' \) -delete
> > > > This patch causes a build error when cross-compiling for RISC-V. I'm using
> > > > the cross-compiler from https://github.com/riscv-collab/riscv-gnu-toolchain.
> > > > When trying to build .debs with:
> > > >
> > > > make CROSS_COMPILE=riscv64-unknown-linux-gnu- ARCH=riscv INSTALL_MOD_STRIP=1
> > > > "KCFLAGS=-mtune=sifive-7-series" LOCALVERSION= bindeb-pkg
> > > >
> > > > I get the following error:
> > > >
> > > > Rebuilding host programs with riscv64-unknown-linux-gnu-gcc...
> > > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/genksyms.o
> > > >    YACC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/parse.tab.[ch]
> > > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/parse.tab.o
> > > >    LEX debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/lex.lex.c
> > > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/lex.lex.o
> > > >    HOSTLD debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/genksyms/genksyms
> > > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/selinux/genheaders/genheaders
> > > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/selinux/mdp/mdp
> > > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/kallsyms
> > > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sorttable
> > > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/asn1_compiler
> > > >    HOSTCC debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sign-file
> > > >
> > > > debian/linux-headers-6.12.0-rc3/usr/src/linux-headers-6.12.0-rc3/scripts/sign-file.c:25:10:
> > > > fatal error: openssl/opensslv.h: No such file or directory
> > > >     25 | #include <openssl/opensslv.h>
> > > >        |          ^~~~~~~~~~~~~~~~~~~~
> > > > compilation terminated.
> > > I guess you have openssl/opensslv.h available on your system, do you?  (In
> > > Debian/Ubuntu package libssl-dev or similar)
> > >
> > > Can you natively build a kernel with a similar kernel config?
> > >
> > > Kind regards,
> > > Nicolas
> >
> > Yes, I have /usr/include/openssl/opensslv.h on my system. But that's the x86
> > version. The cross compiler can't use that.
>
> You'll need to add the package for cross-compilation. If you are using
> ubuntu and the ubuntu riscv64 toolchain, you can add the riscv64
> architecture `dpkg --add-architecture riscv64`, swap out your
> sources.list file to specify the architecture `sed -i 's/^deb/deb
> [arch=amd64]/' /etc/apt/sources.list`, add the riscv64 debs to your
> sources.list:
>
> deb [arch=riscv64] http://ports.ubuntu.com/ubuntu-ports jammy main restricted multiverse universe
> deb [arch=riscv64] http://ports.ubuntu.com/ubuntu-ports jammy-updates main
> deb [arch=riscv64] http://ports.ubuntu.com/ubuntu-ports jammy-security main
>
> Then `apt update` and `apt install libssl-dev:riscv64`. I imagine there
> is a similar procedure for other distros. If using a custom compiler,
> you'll need to copy over the installed headers to whatever location your
> compiler is looking for them.


Right, this build dependency is enforced since commit
e2c318225ac13083cdcb4780cdf5b90edaa8644d






>
> - Charlie
>
> >
> > A native build works fine.
> >
> > Ron
> >
> >



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Jeffrey Hugo]

On 7/27/2024 1:42 AM, Masahiro Yamada wrote:
> Exclude directories and files unnecessary for building external modules:
> 
>   - include/config/  (except include/config/auto.conf)
>   - scripts/atomic/
>   - scripts/dtc/
>   - scripts/kconfig/
>   - scripts/mod/mk_elfconfig
>   - scripts/package/
>   - scripts/unifdef
>   - .config

Please revert this (the removal of .config).

I got some strange reports that our external module install broke, and 
traced it to this change.  Our external module references the .config 
because we have different logic for the build depending on if other, 
related modules are present or not.

Also, it looks like this broke DKMS for some configurations, which not 
only impacts DKMS itself [1] but also downstream projects [2].

While DKMS may be updated going forward to avoid this issue, there are 
plenty of affected version out in the wild.

Also, I haven't surveyed every distro, but it looks like Ubuntu still 
packages the .config with their headers in their upcoming "Plucky" 
release based on 6.12.  I suspect they wouldn't do that if they didn't 
feel it was needed/useful.

-Jeff

[1]: https://github.com/dell/dkms/issues/464
[2]: https://github.com/linux-surface/linux-surface/issues/1654

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Nicolas Schier]

On Tue, Feb 18, 2025 at 01:25:38PM -0700, Jeffrey Hugo wrote:
> On 7/27/2024 1:42 AM, Masahiro Yamada wrote:
> > Exclude directories and files unnecessary for building external modules:
> > 
> >   - include/config/  (except include/config/auto.conf)
> >   - scripts/atomic/
> >   - scripts/dtc/
> >   - scripts/kconfig/
> >   - scripts/mod/mk_elfconfig
> >   - scripts/package/
> >   - scripts/unifdef
> >   - .config
> 
> Please revert this (the removal of .config).
> 
> I got some strange reports that our external module install broke, and
> traced it to this change.  Our external module references the .config
> because we have different logic for the build depending on if other, related
> modules are present or not.
> 
> Also, it looks like this broke DKMS for some configurations, which not only
> impacts DKMS itself [1] but also downstream projects [2].
> 
> While DKMS may be updated going forward to avoid this issue, there are
> plenty of affected version out in the wild.
> 
> Also, I haven't surveyed every distro, but it looks like Ubuntu still
> packages the .config with their headers in their upcoming "Plucky" release
> based on 6.12.  I suspect they wouldn't do that if they didn't feel it was
> needed/useful.
> 
> -Jeff
> 
> [1]: https://github.com/dell/dkms/issues/464
> [2]: https://github.com/linux-surface/linux-surface/issues/1654

Hi Jeff,

do you know the related thread [1]?  According to the last mail, DKMS
has fixed its issue already in December.

Kind regards,
Nicolas

[1]: https://lore.kernel.org/linux-kbuild/CAK7LNARqEOVOzP5vdUVF0KxQBNb9xtYs-COSXXWDMpBzGaLGow@mail.gmail.com/T/#m95f48caf46357a41c1df5e038e227a01ab89dbda

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Jeffrey Hugo]

On 2/20/2025 3:03 AM, Nicolas Schier wrote:
> On Tue, Feb 18, 2025 at 01:25:38PM -0700, Jeffrey Hugo wrote:
>> On 7/27/2024 1:42 AM, Masahiro Yamada wrote:
>>> Exclude directories and files unnecessary for building external modules:
>>>
>>>    - include/config/  (except include/config/auto.conf)
>>>    - scripts/atomic/
>>>    - scripts/dtc/
>>>    - scripts/kconfig/
>>>    - scripts/mod/mk_elfconfig
>>>    - scripts/package/
>>>    - scripts/unifdef
>>>    - .config
>>
>> Please revert this (the removal of .config).
>>
>> I got some strange reports that our external module install broke, and
>> traced it to this change.  Our external module references the .config
>> because we have different logic for the build depending on if other, related
>> modules are present or not.
>>
>> Also, it looks like this broke DKMS for some configurations, which not only
>> impacts DKMS itself [1] but also downstream projects [2].
>>
>> While DKMS may be updated going forward to avoid this issue, there are
>> plenty of affected version out in the wild.
>>
>> Also, I haven't surveyed every distro, but it looks like Ubuntu still
>> packages the .config with their headers in their upcoming "Plucky" release
>> based on 6.12.  I suspect they wouldn't do that if they didn't feel it was
>> needed/useful.
>>
>> -Jeff
>>
>> [1]: https://github.com/dell/dkms/issues/464
>> [2]: https://github.com/linux-surface/linux-surface/issues/1654
> 
> Hi Jeff,
> 
> do you know the related thread [1]?  According to the last mail, DKMS
> has fixed its issue already in December.

DKMS tip might be fixed, but production versions are in various distros, 
which are not updated.  Therefore actual users are impacted by this.

What happened to the #1 rule of kernel, that we do not break users?

This still needs to be reverted.

-Jeff

> 
> Kind regards,
> Nicolas
> 
> [1]: https://lore.kernel.org/linux-kbuild/CAK7LNARqEOVOzP5vdUVF0KxQBNb9xtYs-COSXXWDMpBzGaLGow@mail.gmail.com/T/#m95f48caf46357a41c1df5e038e227a01ab89dbda

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Nicolas Schier]

On Thu, Feb 20, 2025 at 08:03:32AM -0700, Jeffrey Hugo wrote:
> On 2/20/2025 3:03 AM, Nicolas Schier wrote:
> > On Tue, Feb 18, 2025 at 01:25:38PM -0700, Jeffrey Hugo wrote:
> > > On 7/27/2024 1:42 AM, Masahiro Yamada wrote:
> > > > Exclude directories and files unnecessary for building external modules:
> > > > 
> > > >    - include/config/  (except include/config/auto.conf)
> > > >    - scripts/atomic/
> > > >    - scripts/dtc/
> > > >    - scripts/kconfig/
> > > >    - scripts/mod/mk_elfconfig
> > > >    - scripts/package/
> > > >    - scripts/unifdef
> > > >    - .config
> > > 
> > > Please revert this (the removal of .config).
> > > 
> > > I got some strange reports that our external module install broke, and
> > > traced it to this change.  Our external module references the .config
> > > because we have different logic for the build depending on if other, related
> > > modules are present or not.
> > > 
> > > Also, it looks like this broke DKMS for some configurations, which not only
> > > impacts DKMS itself [1] but also downstream projects [2].
> > > 
> > > While DKMS may be updated going forward to avoid this issue, there are
> > > plenty of affected version out in the wild.
> > > 
> > > Also, I haven't surveyed every distro, but it looks like Ubuntu still
> > > packages the .config with their headers in their upcoming "Plucky" release
> > > based on 6.12.  I suspect they wouldn't do that if they didn't feel it was
> > > needed/useful.
> > > 
> > > -Jeff
> > > 
> > > [1]: https://github.com/dell/dkms/issues/464
> > > [2]: https://github.com/linux-surface/linux-surface/issues/1654
> > 
> > Hi Jeff,
> > 
> > do you know the related thread [1]?  According to the last mail, DKMS
> > has fixed its issue already in December.
> 
> DKMS tip might be fixed, but production versions are in various distros,
> which are not updated.  Therefore actual users are impacted by this.
> 
> What happened to the #1 rule of kernel, that we do not break users?

I think, Masahiro already provided valid and profound reasons for
keeping it the way it is.  Users of run-time kernel interfaces are not
affected by the change.  Concretely reported issues were, as far as I
know, only a matter of specific non-official way to work with .config
for other reasons than just building external kernel modules in the way
it is thought to work.

Kind regards,
Nicolas

> This still needs to be reverted.
> 
> -Jeff
> 
> > 
> > Kind regards,
> > Nicolas
> > 
> > [1]: https://lore.kernel.org/linux-kbuild/CAK7LNARqEOVOzP5vdUVF0KxQBNb9xtYs-COSXXWDMpBzGaLGow@mail.gmail.com/T/#m95f48caf46357a41c1df5e038e227a01ab89dbda
> 

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Jeffrey Hugo]

On 2/20/2025 8:54 AM, Nicolas Schier wrote:
> On Thu, Feb 20, 2025 at 08:03:32AM -0700, Jeffrey Hugo wrote:
>> On 2/20/2025 3:03 AM, Nicolas Schier wrote:
>>> On Tue, Feb 18, 2025 at 01:25:38PM -0700, Jeffrey Hugo wrote:
>>>> On 7/27/2024 1:42 AM, Masahiro Yamada wrote:
>>>>> Exclude directories and files unnecessary for building external modules:
>>>>>
>>>>>     - include/config/  (except include/config/auto.conf)
>>>>>     - scripts/atomic/
>>>>>     - scripts/dtc/
>>>>>     - scripts/kconfig/
>>>>>     - scripts/mod/mk_elfconfig
>>>>>     - scripts/package/
>>>>>     - scripts/unifdef
>>>>>     - .config
>>>>
>>>> Please revert this (the removal of .config).
>>>>
>>>> I got some strange reports that our external module install broke, and
>>>> traced it to this change.  Our external module references the .config
>>>> because we have different logic for the build depending on if other, related
>>>> modules are present or not.
>>>>
>>>> Also, it looks like this broke DKMS for some configurations, which not only
>>>> impacts DKMS itself [1] but also downstream projects [2].
>>>>
>>>> While DKMS may be updated going forward to avoid this issue, there are
>>>> plenty of affected version out in the wild.
>>>>
>>>> Also, I haven't surveyed every distro, but it looks like Ubuntu still
>>>> packages the .config with their headers in their upcoming "Plucky" release
>>>> based on 6.12.  I suspect they wouldn't do that if they didn't feel it was
>>>> needed/useful.
>>>>
>>>> -Jeff
>>>>
>>>> [1]: https://github.com/dell/dkms/issues/464
>>>> [2]: https://github.com/linux-surface/linux-surface/issues/1654
>>>
>>> Hi Jeff,
>>>
>>> do you know the related thread [1]?  According to the last mail, DKMS
>>> has fixed its issue already in December.
>>
>> DKMS tip might be fixed, but production versions are in various distros,
>> which are not updated.  Therefore actual users are impacted by this.
>>
>> What happened to the #1 rule of kernel, that we do not break users?
> 
> I think, Masahiro already provided valid and profound reasons for
> keeping it the way it is.  Users of run-time kernel interfaces are not
> affected by the change.  Concretely reported issues were, as far as I
> know, only a matter of specific non-official way to work with .config
> for other reasons than just building external kernel modules in the way
> it is thought to work.

I'm CCing the regressions list, which I probably should have done initially.

I'm pretty sure Linus has indicated that as soon as users start doing 
something, that becomes the "official way".  I believe your response is 
not consistent with the precedent set by Linus.

Quoting from [1]:
It’s a regression if some application or practical use case running fine 
with one Linux kernel works worse or not at all with a newer version 
compiled using a similar configuration. The “no regressions” rule 
forbids this to take place; if it happens by accident, developers that 
caused it are expected to quickly fix the issue."

As far as I understand its not acceptable to force users to change (the 
DKMS fix) or update userspace to work with a new kernel.  You could make 
a change if userspace updated, and all old versions needing the previous 
behavior were phased out of use, but we have 2 reports indicating that 
is not the case.

 From the thread you pointed out, it looks like Masahiro recommends 
${kernel_source_dir}/include/config/auto.conf as a replacement for the 
.config.  Ignoring that such a suggestion seems to violate the 
regressions rule, doing a diff of that and the .config on a 6.11 build 
(before the change we are discussing), there are many changes.  It does 
not look like that is an equivalent replacement.

Are we at an impasse?  Masahiro has not chimed in, which is quite 
disappointing.  So far, I don't think your responses justify why 
breaking users is acceptable.  This is not a security fix - the only 
justification for this change is that .config is not needed, but I argue 
that has been proven false.  It seems like I am not convincing you.

-Jeff

[1]: https://docs.kernel.org/admin-guide/reporting-regressions.html

> Kind regards,
> Nicolas
> 
>> This still needs to be reverted.
>>
>> -Jeff
>>
>>>
>>> Kind regards,
>>> Nicolas
>>>
>>> [1]: https://lore.kernel.org/linux-kbuild/CAK7LNARqEOVOzP5vdUVF0KxQBNb9xtYs-COSXXWDMpBzGaLGow@mail.gmail.com/T/#m95f48caf46357a41c1df5e038e227a01ab89dbda
>>

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Greg KH]

On Thu, Feb 20, 2025 at 09:31:14AM -0700, Jeffrey Hugo wrote:
> On 2/20/2025 8:54 AM, Nicolas Schier wrote:
> > On Thu, Feb 20, 2025 at 08:03:32AM -0700, Jeffrey Hugo wrote:
> > > On 2/20/2025 3:03 AM, Nicolas Schier wrote:
> > > > On Tue, Feb 18, 2025 at 01:25:38PM -0700, Jeffrey Hugo wrote:
> > > > > On 7/27/2024 1:42 AM, Masahiro Yamada wrote:
> > > > > > Exclude directories and files unnecessary for building external modules:
> > > > > > 
> > > > > >     - include/config/  (except include/config/auto.conf)
> > > > > >     - scripts/atomic/
> > > > > >     - scripts/dtc/
> > > > > >     - scripts/kconfig/
> > > > > >     - scripts/mod/mk_elfconfig
> > > > > >     - scripts/package/
> > > > > >     - scripts/unifdef
> > > > > >     - .config
> > > > > 
> > > > > Please revert this (the removal of .config).
> > > > > 
> > > > > I got some strange reports that our external module install broke, and
> > > > > traced it to this change.  Our external module references the .config
> > > > > because we have different logic for the build depending on if other, related
> > > > > modules are present or not.
> > > > > 
> > > > > Also, it looks like this broke DKMS for some configurations, which not only
> > > > > impacts DKMS itself [1] but also downstream projects [2].
> > > > > 
> > > > > While DKMS may be updated going forward to avoid this issue, there are
> > > > > plenty of affected version out in the wild.
> > > > > 
> > > > > Also, I haven't surveyed every distro, but it looks like Ubuntu still
> > > > > packages the .config with their headers in their upcoming "Plucky" release
> > > > > based on 6.12.  I suspect they wouldn't do that if they didn't feel it was
> > > > > needed/useful.
> > > > > 
> > > > > -Jeff
> > > > > 
> > > > > [1]: https://github.com/dell/dkms/issues/464
> > > > > [2]: https://github.com/linux-surface/linux-surface/issues/1654
> > > > 
> > > > Hi Jeff,
> > > > 
> > > > do you know the related thread [1]?  According to the last mail, DKMS
> > > > has fixed its issue already in December.
> > > 
> > > DKMS tip might be fixed, but production versions are in various distros,
> > > which are not updated.  Therefore actual users are impacted by this.
> > > 
> > > What happened to the #1 rule of kernel, that we do not break users?
> > 
> > I think, Masahiro already provided valid and profound reasons for
> > keeping it the way it is.  Users of run-time kernel interfaces are not
> > affected by the change.  Concretely reported issues were, as far as I
> > know, only a matter of specific non-official way to work with .config
> > for other reasons than just building external kernel modules in the way
> > it is thought to work.
> 
> I'm CCing the regressions list, which I probably should have done initially.
> 
> I'm pretty sure Linus has indicated that as soon as users start doing
> something, that becomes the "official way".  I believe your response is not
> consistent with the precedent set by Linus.
> 
> Quoting from [1]:
> It’s a regression if some application or practical use case running fine
> with one Linux kernel works worse or not at all with a newer version
> compiled using a similar configuration. The “no regressions” rule forbids
> this to take place; if it happens by accident, developers that caused it are
> expected to quickly fix the issue."

Regressions are at runtime, not with how external tools poke around in
kernel source trees and try to make decisions.  If we were to never be
able to change our source just because there might be an external user
that we don't know of, that would be crazy.

We want users to not be afraid to upgrade their kernel, that has nothing
to do with how the kernel build is interacted with external stuff.

> As far as I understand its not acceptable to force users to change (the DKMS
> fix) or update userspace to work with a new kernel.  You could make a change
> if userspace updated, and all old versions needing the previous behavior
> were phased out of use, but we have 2 reports indicating that is not the
> case.

You are attempting to build kernel modules outside of the kernel tree,
and as such, have to adapt to things when they change.  That's always
been the case, you've had to change things many times over the years,
right?

> From the thread you pointed out, it looks like Masahiro recommends
> ${kernel_source_dir}/include/config/auto.conf as a replacement for the
> .config.  Ignoring that such a suggestion seems to violate the regressions
> rule, doing a diff of that and the .config on a 6.11 build (before the
> change we are discussing), there are many changes.  It does not look like
> that is an equivalent replacement.

What do you need/want to parse the .config file in the first place?  Why
not rely on the generated .h files instead as those can be parsed the
same way as before, right?

thanks,

greg k-h

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Jeffrey Hugo]

On 2/20/2025 9:49 AM, Greg KH wrote:
> On Thu, Feb 20, 2025 at 09:31:14AM -0700, Jeffrey Hugo wrote:
>> On 2/20/2025 8:54 AM, Nicolas Schier wrote:
>>> On Thu, Feb 20, 2025 at 08:03:32AM -0700, Jeffrey Hugo wrote:
>>>> On 2/20/2025 3:03 AM, Nicolas Schier wrote:
>>>>> On Tue, Feb 18, 2025 at 01:25:38PM -0700, Jeffrey Hugo wrote:
>>>>>> On 7/27/2024 1:42 AM, Masahiro Yamada wrote:
>>>>>>> Exclude directories and files unnecessary for building external modules:
>>>>>>>
>>>>>>>      - include/config/  (except include/config/auto.conf)
>>>>>>>      - scripts/atomic/
>>>>>>>      - scripts/dtc/
>>>>>>>      - scripts/kconfig/
>>>>>>>      - scripts/mod/mk_elfconfig
>>>>>>>      - scripts/package/
>>>>>>>      - scripts/unifdef
>>>>>>>      - .config
>>>>>>
>>>>>> Please revert this (the removal of .config).
>>>>>>
>>>>>> I got some strange reports that our external module install broke, and
>>>>>> traced it to this change.  Our external module references the .config
>>>>>> because we have different logic for the build depending on if other, related
>>>>>> modules are present or not.
>>>>>>
>>>>>> Also, it looks like this broke DKMS for some configurations, which not only
>>>>>> impacts DKMS itself [1] but also downstream projects [2].
>>>>>>
>>>>>> While DKMS may be updated going forward to avoid this issue, there are
>>>>>> plenty of affected version out in the wild.
>>>>>>
>>>>>> Also, I haven't surveyed every distro, but it looks like Ubuntu still
>>>>>> packages the .config with their headers in their upcoming "Plucky" release
>>>>>> based on 6.12.  I suspect they wouldn't do that if they didn't feel it was
>>>>>> needed/useful.
>>>>>>
>>>>>> -Jeff
>>>>>>
>>>>>> [1]: https://github.com/dell/dkms/issues/464
>>>>>> [2]: https://github.com/linux-surface/linux-surface/issues/1654
>>>>>
>>>>> Hi Jeff,
>>>>>
>>>>> do you know the related thread [1]?  According to the last mail, DKMS
>>>>> has fixed its issue already in December.
>>>>
>>>> DKMS tip might be fixed, but production versions are in various distros,
>>>> which are not updated.  Therefore actual users are impacted by this.
>>>>
>>>> What happened to the #1 rule of kernel, that we do not break users?
>>>
>>> I think, Masahiro already provided valid and profound reasons for
>>> keeping it the way it is.  Users of run-time kernel interfaces are not
>>> affected by the change.  Concretely reported issues were, as far as I
>>> know, only a matter of specific non-official way to work with .config
>>> for other reasons than just building external kernel modules in the way
>>> it is thought to work.
>>
>> I'm CCing the regressions list, which I probably should have done initially.
>>
>> I'm pretty sure Linus has indicated that as soon as users start doing
>> something, that becomes the "official way".  I believe your response is not
>> consistent with the precedent set by Linus.
>>
>> Quoting from [1]:
>> It’s a regression if some application or practical use case running fine
>> with one Linux kernel works worse or not at all with a newer version
>> compiled using a similar configuration. The “no regressions” rule forbids
>> this to take place; if it happens by accident, developers that caused it are
>> expected to quickly fix the issue."
> 
> Regressions are at runtime, not with how external tools poke around in
> kernel source trees and try to make decisions.  If we were to never be
> able to change our source just because there might be an external user
> that we don't know of, that would be crazy.

As a kernel developer, I get this.  The MAX_ORDER thing from a few 
versions ago seemed to make this a grey area.  Perhaps it a case by case 
thing.  In which case, what is the harm in sharing the kernel's .config 
which has been a thing since I started kernel development back in the 
2.6.X times?

> We want users to not be afraid to upgrade their kernel, that has nothing
> to do with how the kernel build is interacted with external stuff.
 > >> As far as I understand its not acceptable to force users to change 
(the DKMS
>> fix) or update userspace to work with a new kernel.  You could make a change
>> if userspace updated, and all old versions needing the previous behavior
>> were phased out of use, but we have 2 reports indicating that is not the
>> case.
> 
> You are attempting to build kernel modules outside of the kernel tree,
> and as such, have to adapt to things when they change.  That's always
> been the case, you've had to change things many times over the years,
> right?

While true, its possible to build an external module against 6.11 and 
6.12 and still hit a failure because of this change (see below about DKMS).

> 
>>  From the thread you pointed out, it looks like Masahiro recommends
>> ${kernel_source_dir}/include/config/auto.conf as a replacement for the
>> .config.  Ignoring that such a suggestion seems to violate the regressions
>> rule, doing a diff of that and the .config on a 6.11 build (before the
>> change we are discussing), there are many changes.  It does not look like
>> that is an equivalent replacement.
> 
> What do you need/want to parse the .config file in the first place?  Why
> not rely on the generated .h files instead as those can be parsed the
> same way as before, right?

Two usecases -

First when secure boot is enabled, DKMS looks for CONFIG_MODULE_SIG_HASH 
to figure out signing the modules so that they can be loaded.  Removing 
.config causes an error in DKMS and the module signing process will 
fail.  The resulting modules (already compiled successfully) will fail 
to load.  Whatever the user needed those modules for will no longer work.

If the user is on Ubuntu, and has built a kernel 6.12 or later, they 
need to build upstream DKMS and use it as none of the Canonical provided 
DKMS builds have the fix.  This feels like a situation that would make 
the user afraid to upgrade their kernel (to your point above).

This feels very much like an "at runtime" issue, assuming external 
modules are supported.  I may be wrong here.

I'm not a DKMS developer, but I do use it, and find it extremely handy 
to take latest upstream code and apply it older kernels that customers 
seem to want to use.

Second, our usecase is that we look at the .config to tell if a 
particular driver is included in the kernel build (config =y or =m). 
This driver provides diagnostic information which is useful to our 
product, but not required for operation.  It does not have headers that 
are exposed to the rest of the kernel, so checking the generated .h 
files does not work.  If the driver is not built, we provide a 
backported version that is then built out of tree.

I can, with effort, extend the logic to first look for a .config (since 
the distros provide that), and if not, then look for the auto.conf 
(assuming that doesn't get determined to be not useful) to kick off our 
logic.  We'd still face the DKMS issue above so my preference would be a 
revert since it addresses both problems.

-Jeff

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Greg KH]

On Thu, Feb 20, 2025 at 10:24:32AM -0700, Jeffrey Hugo wrote:
> On 2/20/2025 9:49 AM, Greg KH wrote:
> > What do you need/want to parse the .config file in the first place?  Why
> > not rely on the generated .h files instead as those can be parsed the
> > same way as before, right?
> 
> Two usecases -
> 
> First when secure boot is enabled, DKMS looks for CONFIG_MODULE_SIG_HASH to
> figure out signing the modules so that they can be loaded.  Removing .config
> causes an error in DKMS and the module signing process will fail.  The
> resulting modules (already compiled successfully) will fail to load.
> Whatever the user needed those modules for will no longer work.

Shouldn't the "normal" kbuild process properly sign the module if it
needs to be signed?  Or are you trying to do this "by hand"?

> If the user is on Ubuntu, and has built a kernel 6.12 or later, they need to
> build upstream DKMS and use it as none of the Canonical provided DKMS builds
> have the fix.  This feels like a situation that would make the user afraid
> to upgrade their kernel (to your point above).
> 
> This feels very much like an "at runtime" issue, assuming external modules
> are supported.  I may be wrong here.

external modules can be broken at any moment in time, you know that.
There's never a guarantee for that at all.

> Second, our usecase is that we look at the .config to tell if a particular
> driver is included in the kernel build (config =y or =m). This driver
> provides diagnostic information which is useful to our product, but not
> required for operation.  It does not have headers that are exposed to the
> rest of the kernel, so checking the generated .h files does not work.  If
> the driver is not built, we provide a backported version that is then built
> out of tree.

You can check the same .h files for those config options, no need to
manually parse a .config file.  What's wrong with including
include/generated/autoconf.h properly?  That's what the build system
uses, right?

thanks,

greg k-h

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Masahiro Yamada]

On Fri, Feb 21, 2025 at 2:24 AM Jeffrey Hugo <quic_jhugo@quicinc.com> wrote:
>
> On 2/20/2025 9:49 AM, Greg KH wrote:
> > On Thu, Feb 20, 2025 at 09:31:14AM -0700, Jeffrey Hugo wrote:
> >> On 2/20/2025 8:54 AM, Nicolas Schier wrote:
> >>> On Thu, Feb 20, 2025 at 08:03:32AM -0700, Jeffrey Hugo wrote:
> >>>> On 2/20/2025 3:03 AM, Nicolas Schier wrote:
> >>>>> On Tue, Feb 18, 2025 at 01:25:38PM -0700, Jeffrey Hugo wrote:
> >>>>>> On 7/27/2024 1:42 AM, Masahiro Yamada wrote:
> >>>>>>> Exclude directories and files unnecessary for building external modules:
> >>>>>>>
> >>>>>>>      - include/config/  (except include/config/auto.conf)
> >>>>>>>      - scripts/atomic/
> >>>>>>>      - scripts/dtc/
> >>>>>>>      - scripts/kconfig/
> >>>>>>>      - scripts/mod/mk_elfconfig
> >>>>>>>      - scripts/package/
> >>>>>>>      - scripts/unifdef
> >>>>>>>      - .config
> >>>>>>
> >>>>>> Please revert this (the removal of .config).
> >>>>>>
> >>>>>> I got some strange reports that our external module install broke, and
> >>>>>> traced it to this change.  Our external module references the .config
> >>>>>> because we have different logic for the build depending on if other, related
> >>>>>> modules are present or not.
> >>>>>>
> >>>>>> Also, it looks like this broke DKMS for some configurations, which not only
> >>>>>> impacts DKMS itself [1] but also downstream projects [2].
> >>>>>>
> >>>>>> While DKMS may be updated going forward to avoid this issue, there are
> >>>>>> plenty of affected version out in the wild.
> >>>>>>
> >>>>>> Also, I haven't surveyed every distro, but it looks like Ubuntu still
> >>>>>> packages the .config with their headers in their upcoming "Plucky" release
> >>>>>> based on 6.12.  I suspect they wouldn't do that if they didn't feel it was
> >>>>>> needed/useful.
> >>>>>>
> >>>>>> -Jeff
> >>>>>>
> >>>>>> [1]: https://github.com/dell/dkms/issues/464
> >>>>>> [2]: https://github.com/linux-surface/linux-surface/issues/1654
> >>>>>
> >>>>> Hi Jeff,
> >>>>>
> >>>>> do you know the related thread [1]?  According to the last mail, DKMS
> >>>>> has fixed its issue already in December.
> >>>>
> >>>> DKMS tip might be fixed, but production versions are in various distros,
> >>>> which are not updated.  Therefore actual users are impacted by this.
> >>>>
> >>>> What happened to the #1 rule of kernel, that we do not break users?
> >>>
> >>> I think, Masahiro already provided valid and profound reasons for
> >>> keeping it the way it is.  Users of run-time kernel interfaces are not
> >>> affected by the change.  Concretely reported issues were, as far as I
> >>> know, only a matter of specific non-official way to work with .config
> >>> for other reasons than just building external kernel modules in the way
> >>> it is thought to work.
> >>
> >> I'm CCing the regressions list, which I probably should have done initially.
> >>
> >> I'm pretty sure Linus has indicated that as soon as users start doing
> >> something, that becomes the "official way".  I believe your response is not
> >> consistent with the precedent set by Linus.
> >>
> >> Quoting from [1]:
> >> It’s a regression if some application or practical use case running fine
> >> with one Linux kernel works worse or not at all with a newer version
> >> compiled using a similar configuration. The “no regressions” rule forbids
> >> this to take place; if it happens by accident, developers that caused it are
> >> expected to quickly fix the issue."
> >
> > Regressions are at runtime, not with how external tools poke around in
> > kernel source trees and try to make decisions.  If we were to never be
> > able to change our source just because there might be an external user
> > that we don't know of, that would be crazy.
>
> As a kernel developer, I get this.  The MAX_ORDER thing from a few
> versions ago seemed to make this a grey area.  Perhaps it a case by case
> thing.  In which case, what is the harm in sharing the kernel's .config
> which has been a thing since I started kernel development back in the
> 2.6.X times?
>
> > We want users to not be afraid to upgrade their kernel, that has nothing
> > to do with how the kernel build is interacted with external stuff.
>  > >> As far as I understand its not acceptable to force users to change
> (the DKMS
> >> fix) or update userspace to work with a new kernel.  You could make a change
> >> if userspace updated, and all old versions needing the previous behavior
> >> were phased out of use, but we have 2 reports indicating that is not the
> >> case.
> >
> > You are attempting to build kernel modules outside of the kernel tree,
> > and as such, have to adapt to things when they change.  That's always
> > been the case, you've had to change things many times over the years,
> > right?
>
> While true, its possible to build an external module against 6.11 and
> 6.12 and still hit a failure because of this change (see below about DKMS).
>
> >
> >>  From the thread you pointed out, it looks like Masahiro recommends
> >> ${kernel_source_dir}/include/config/auto.conf as a replacement for the
> >> .config.  Ignoring that such a suggestion seems to violate the regressions
> >> rule, doing a diff of that and the .config on a 6.11 build (before the
> >> change we are discussing), there are many changes.  It does not look like
> >> that is an equivalent replacement.
> >
> > What do you need/want to parse the .config file in the first place?  Why
> > not rely on the generated .h files instead as those can be parsed the
> > same way as before, right?
>
> Two usecases -
>
> First when secure boot is enabled, DKMS looks for CONFIG_MODULE_SIG_HASH
> to figure out signing the modules so that they can be loaded.  Removing
> .config causes an error in DKMS and the module signing process will
> fail.  The resulting modules (already compiled successfully) will fail
> to load.  Whatever the user needed those modules for will no longer work.
>
> If the user is on Ubuntu, and has built a kernel 6.12 or later, they
> need to build upstream DKMS and use it as none of the Canonical provided
> DKMS builds have the fix.  This feels like a situation that would make
> the user afraid to upgrade their kernel (to your point above).
>
> This feels very much like an "at runtime" issue, assuming external
> modules are supported.  I may be wrong here.
>
> I'm not a DKMS developer, but I do use it, and find it extremely handy
> to take latest upstream code and apply it older kernels that customers
> seem to want to use.
>
> Second, our usecase is that we look at the .config to tell if a
> particular driver is included in the kernel build (config =y or =m).
> This driver provides diagnostic information which is useful to our
> product, but not required for operation.  It does not have headers that
> are exposed to the rest of the kernel, so checking the generated .h
> files does not work.  If the driver is not built, we provide a
> backported version that is then built out of tree.

External modules should not parse the .config.
It was documented 20 years ago.

See the bottom of this:
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=65e433436b5794ae056d22ddba60fe9194bba007

"External modules have traditionally used grep to check for specific
 CONFIG_ settings directly in .config. This usage is broken.
As introduced before external modules shall use kbuild when building
and therefore can use the same methods as in-kernel modules when testing
for CONFIG_ definitions.
"

The commit date is 2004.

The .config is a saved kernel configuration.
Kbuild does not use it at compile time.
External modules should follow the Kbuild rule
(that is, use include/config/auto.conf instead)


While commit 1a59bd3ca5d8fde10d082e56c3073f7fa563e73b
deleted it, the reason is this information is stale.
If we do not ship the .config in the package,
we do not need to say "do not parse .config".


You repeatedly fail to understand the regression in this context.
We promise backward-compatibility for userspace interfaces.
(system calls, UAPI headers, etc.)

We do not promise anything to external modules:
 - Header files under include/ (except uapi/) are changed without caring
   about the breakage of external modules
 - EXPORT_SYMBOL is dropped if no user is present in upstream



>
> I can, with effort, extend the logic to first look for a .config (since
> the distros provide that), and if not, then look for the auto.conf
> (assuming that doesn't get determined to be not useful) to kick off our
> logic.  We'd still face the DKMS issue above so my preference would be a
> revert since it addresses both problems.
>
> -Jeff
>
>
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Masahiro Yamada]

On Fri, Feb 21, 2025 at 2:43 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Feb 20, 2025 at 10:24:32AM -0700, Jeffrey Hugo wrote:
> > On 2/20/2025 9:49 AM, Greg KH wrote:
> > > What do you need/want to parse the .config file in the first place?  Why
> > > not rely on the generated .h files instead as those can be parsed the
> > > same way as before, right?
> >
> > Two usecases -
> >
> > First when secure boot is enabled, DKMS looks for CONFIG_MODULE_SIG_HASH to
> > figure out signing the modules so that they can be loaded.  Removing .config
> > causes an error in DKMS and the module signing process will fail.  The
> > resulting modules (already compiled successfully) will fail to load.
> > Whatever the user needed those modules for will no longer work.
>
> Shouldn't the "normal" kbuild process properly sign the module if it
> needs to be signed?  Or are you trying to do this "by hand"?

You can ignore this.
This is not related to the upstream module signing.

He is just explaining how DKMS greps CONFIG_MODULE_SIG_HASH.

See this line:
https://github.com/dell/dkms/blob/v3.1.5/dkms.in#L1113

The upstream kernel documentation said "do not grep .config" many years ago.
The latest DKMS has been fixed.



>
> > If the user is on Ubuntu, and has built a kernel 6.12 or later, they need to
> > build upstream DKMS and use it as none of the Canonical provided DKMS builds
> > have the fix.  This feels like a situation that would make the user afraid
> > to upgrade their kernel (to your point above).
> >
> > This feels very much like an "at runtime" issue, assuming external modules
> > are supported.  I may be wrong here.
>
> external modules can be broken at any moment in time, you know that.
> There's never a guarantee for that at all.
>
> > Second, our usecase is that we look at the .config to tell if a particular
> > driver is included in the kernel build (config =y or =m). This driver
> > provides diagnostic information which is useful to our product, but not
> > required for operation.  It does not have headers that are exposed to the
> > rest of the kernel, so checking the generated .h files does not work.  If
> > the driver is not built, we provide a backported version that is then built
> > out of tree.
>
> You can check the same .h files for those config options, no need to
> manually parse a .config file.  What's wrong with including
> include/generated/autoconf.h properly?  That's what the build system
> uses, right?

Upstream uses include/config/auto.conf
External modules can do the same.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH 3/4] kbuild: slim down package for building external modules

[Jeffrey Hugo]

On 2/20/2025 10:43 AM, Greg KH wrote:
> On Thu, Feb 20, 2025 at 10:24:32AM -0700, Jeffrey Hugo wrote:
>> On 2/20/2025 9:49 AM, Greg KH wrote:
>>> What do you need/want to parse the .config file in the first place?  Why
>>> not rely on the generated .h files instead as those can be parsed the
>>> same way as before, right?
>>
>> Two usecases -
>>
>> First when secure boot is enabled, DKMS looks for CONFIG_MODULE_SIG_HASH to
>> figure out signing the modules so that they can be loaded.  Removing .config
>> causes an error in DKMS and the module signing process will fail.  The
>> resulting modules (already compiled successfully) will fail to load.
>> Whatever the user needed those modules for will no longer work.
> 
> Shouldn't the "normal" kbuild process properly sign the module if it
> needs to be signed?  Or are you trying to do this "by hand"?
> 
>> If the user is on Ubuntu, and has built a kernel 6.12 or later, they need to
>> build upstream DKMS and use it as none of the Canonical provided DKMS builds
>> have the fix.  This feels like a situation that would make the user afraid
>> to upgrade their kernel (to your point above).
>>
>> This feels very much like an "at runtime" issue, assuming external modules
>> are supported.  I may be wrong here.
> 
> external modules can be broken at any moment in time, you know that.
> There's never a guarantee for that at all.
> 
>> Second, our usecase is that we look at the .config to tell if a particular
>> driver is included in the kernel build (config =y or =m). This driver
>> provides diagnostic information which is useful to our product, but not
>> required for operation.  It does not have headers that are exposed to the
>> rest of the kernel, so checking the generated .h files does not work.  If
>> the driver is not built, we provide a backported version that is then built
>> out of tree.
> 
> You can check the same .h files for those config options, no need to
> manually parse a .config file.  What's wrong with including
> include/generated/autoconf.h properly?  That's what the build system
> uses, right?

I can't check .h files that don't exist.

However, I think your viewpoint is coming through pretty clear - we'll 
fix up what we can in our control, and I guess anything else gets 
dropped on the floor.  Seems like I have a conclusion.

-Jeff