This work was prompted by the criticism about the recent Kconfig change:
https://lkml.org/lkml/2018/6/27/254
I may not fully understand his concern, though.
Masahiro Yamada (3):
kconfig: support an environment variable for non-interactive
syncconfig
kbuild: rpm-pkg: hard-code ARCH in RPM SPEC file
kbuild: rpm-pkg: set KCONFIG_NONINTERACTIVE_UPDATE
Documentation/kbuild/kconfig.txt | 6 ++++++
scripts/kconfig/conf.c | 5 +++++
scripts/package/mkspec | 23 +++++++++++++----------
3 files changed, 24 insertions(+), 10 deletions(-)
--
2.7.4
When Kconfig files are updated, or build environments etc. are changed,
'make syncconfig' is invoked, which will show prompts if new config
options are available. Users must explicitly input values for all
new symbols. This is the conventional behavior for the kernel build.
However, it would be useful to process this non-interactively in such
cases as package building.
Package maintainers create source packages with the .config configured
on their machines. Package builders may work on different machine
environments, where different compilers are installed.
With the recent changes in Kconfig, the .config contents depend on
the compiler. During package building, it is not sensible to show
prompts for new symbols; it would be just annoys script automation.
Add a new switch, KCONFIG_NONINTERACTIVE_UPDATE. If this environment
variable is set, Kconfig will sync the configuration non-interactively.
All new symbols are silently set to their default values.
Signed-off-by: Masahiro Yamada <[email protected]>
---
Documentation/kbuild/kconfig.txt | 6 ++++++
scripts/kconfig/conf.c | 5 +++++
2 files changed, 11 insertions(+)
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index 68c8291..5c29c3f 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -129,6 +129,12 @@ KCONFIG_NOSILENTUPDATE
If this variable has a non-blank value, it prevents silent kernel
config updates (requires explicit updates).
+KCONFIG_NONINTERACTIVE_UPDATE
+--------------------------------------------------
+If this variable has a non-blank value, it prevents user input prompts
+from showing up even when new symbols are available. All new symbols
+are silently set to their default values.
+
KCONFIG_AUTOCONFIG
--------------------------------------------------
This environment variable can be set to specify the path & name of the
diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 7b2b372..b64bbc0 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -680,6 +680,11 @@ int main(int ac, char **av)
case oldconfig:
case listnewconfig:
case syncconfig:
+ if (input_mode == syncconfig) {
+ name = getenv("KCONFIG_NONINTERACTIVE_UPDATE");
+ if (name && *name)
+ break;
+ }
/* Update until a loop caused no more changes */
do {
conf_cnt = 0;
--
2.7.4
Prevent "make syncconfig" from prompting user inputs when new symbols
become available due to build environment changes.
Signed-off-by: Masahiro Yamada <[email protected]>
---
scripts/package/mkspec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/package/mkspec b/scripts/package/mkspec
index f72c46a..86986c1 100755
--- a/scripts/package/mkspec
+++ b/scripts/package/mkspec
@@ -87,7 +87,7 @@ $S %prep
$S %setup -q
$S
$S %build
-$S make %{?_smp_mflags} ARCH=$ARCH KBUILD_BUILD_VERSION=%{release}
+$S make %{?_smp_mflags} ARCH=$ARCH KBUILD_BUILD_VERSION=%{release} KCONFIG_NONINTERACTIVE_UPDATE=1
$S
%install
mkdir -p %{buildroot}/boot
--
2.7.4
The kernel source package contains the .config, which is ARCH-specific.
Obviously, the target architecture is specified when you create a
source package, instead of build-time.
Record ARCH= in the spec file in order to avoid uncertainty about
what ARCH should be given for building.
Add 'ExclusiveArch' tag to stop building immediately in case a user
tries to build it for an unintended architecture.
Signed-off-by: Masahiro Yamada <[email protected]>
---
scripts/package/mkspec | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/scripts/package/mkspec b/scripts/package/mkspec
index e05646d..f72c46a 100755
--- a/scripts/package/mkspec
+++ b/scripts/package/mkspec
@@ -26,6 +26,14 @@ if grep -q CONFIG_DRM=y .config; then
PROVIDES=kernel-drm
fi
+if [ "$ARCH" = ia64 ]; then
+ INSTALL_IMAGE="mkdir -p %{buildroot}/boot/efi
+ cp $KBUILD_IMAGE %{buildroot}/boot/efi/vmlinuz-$KERNELRELEASE
+ ln -s efi/vmlinuz-$KERNELRELEASE %{buildroot}/boot/"
+else
+ INSTALL_IMAGE="cp $KBUILD_IMAGE %{buildroot}/boot/vmlinuz-$KERNELRELEASE"
+fi
+
PROVIDES="$PROVIDES kernel-$KERNELRELEASE"
__KERNELRELEASE=$(echo $KERNELRELEASE | sed -e "s/-/_/g")
EXCLUDES="$RCS_TAR_IGNORE --exclude=.tmp_versions --exclude=*vmlinux* \
@@ -47,6 +55,7 @@ sed -e '/^DEL/d' -e 's/^\t*//' <<EOF
Vendor: The Linux Community
URL: http://www.kernel.org
$S Source: kernel-$__KERNELRELEASE.tar.gz
+ ExclusiveArch: $UTS_MACHINE
Provides: $PROVIDES
%define __spec_install_post /usr/lib/rpm/brp-compress || :
%define debug_package %{nil}
@@ -78,19 +87,13 @@ $S %prep
$S %setup -q
$S
$S %build
-$S make %{?_smp_mflags} KBUILD_BUILD_VERSION=%{release}
+$S make %{?_smp_mflags} ARCH=$ARCH KBUILD_BUILD_VERSION=%{release}
$S
%install
mkdir -p %{buildroot}/boot
- %ifarch ia64
- mkdir -p %{buildroot}/boot/efi
- cp \$(make image_name) %{buildroot}/boot/efi/vmlinuz-$KERNELRELEASE
- ln -s efi/vmlinuz-$KERNELRELEASE %{buildroot}/boot/
- %else
- cp \$(make image_name) %{buildroot}/boot/vmlinuz-$KERNELRELEASE
- %endif
-$M make %{?_smp_mflags} INSTALL_MOD_PATH=%{buildroot} KBUILD_SRC= modules_install
- make %{?_smp_mflags} INSTALL_HDR_PATH=%{buildroot}/usr KBUILD_SRC= headers_install
+ $INSTALL_IMAGE
+$M make %{?_smp_mflags} ARCH=$ARCH INSTALL_MOD_PATH=%{buildroot} KBUILD_SRC= modules_install
+ make %{?_smp_mflags} ARCH=$ARCH INSTALL_HDR_PATH=%{buildroot}/usr KBUILD_SRC= headers_install
cp System.map %{buildroot}/boot/System.map-$KERNELRELEASE
cp .config %{buildroot}/boot/config-$KERNELRELEASE
bzip2 -9 --keep vmlinux
--
2.7.4
On 9/3/18 6:01 AM, Masahiro Yamada wrote:
> This work was prompted by the criticism about the recent Kconfig change:
> https://lkml.org/lkml/2018/6/27/254
>
> I may not fully understand his concern, though.
I don't think you do.
Here's the use case for us and, I expect, most distro kernel maintainers
out there. We build kernels on 8 architectures, with 3 or more configs
for each architecture. Each product release uses a different build
environment. Between SLE and openSUSE we have 6 build environments at
the moment. Our update process for configs is to run a script that adds
the change to every affected config and then run a script that does a
'make oldconfig' on every architecture/config combination to sync them
up and ensure options that may have been enabled by the change are
synced up. Those changes are also automatically propagated to other
configs. The config updates can be done on pretty much any linux system
capable of building a kernel. This is a process that has worked for us
for at least 15 years. It doesn't now with the GCC_VERSION changes.
Today, I went to do a simple config change: disable an option on every
arch/config combination for a single branch (that wasn't the one that
matched the build environment of the running system) and instead of it
running more or less silently as it has for years, it wanted to change
all the compiler options. Of course, those changes shouldn't be pushed
to the repository because they'll be wrong for the build environment.
In this simple example it was easy to just modify the option in-place,
but it would've been painful if I was enabling an option that guarded
other new options instead.
Lastly, we fail our builds if there are unresolved config options. A
build that silently ignored them and accepted defaults isn't something
we'd use. Otherwise, we could start our builds with yes '' | make
oldconfig and be done with it.
Requiring the config to be generated using the same environment that
will ultimately build the kernel is a huge usability regression for us
and, I would assume, others.
-Jeff
--
Jeff Mahoney
SUSE Labs