Thread (13 messages) 13 messages, 4 authors, 2018-09-03

Re: due to kconfig changes kernel config file is no longer sufficient for configuring the kernel

From: Masahiro Yamada <hidden>
Date: 2018-06-27 14:08:16
Also in: linux-kbuild, linux-sh, linux-um, lkml, sparclinux

Hi.


2018-06-27 21:37 GMT+09:00 Michal Suchánek [off-list ref]:
Hello,

in the x86 Kconfig we have this:

# Select 32 or 64 bit
config 64BIT
        bool "64-bit kernel" if "$(ARCH)" = "x86"
        default "$(ARCH)" != "i386"
        ---help---
          Say yes to build a 64-bit kernel - formerly known as x86_64
          Say no to build a 32-bit kernel - formerly known as i386

Since commit 104daea149c4 ("kconfig: reference environment variables
directly and remove 'option env='") the value of ARCH is not saved in
the kernel config.
I think this commit is unrelated.  It was just a syntax change.

Unless I am missing something,
we have never saved ARCH in the .config in the past.

Since commit f467c5640c29 ("kconfig: only write '#
CONFIG_FOO is not set' for visible symbols") the value of 64BIT is not
saved if the ARCH is set i386 or x86_64 because the symbol is not
visible.
This is correct.

It was discussed a few weeks ago.

https://lkml.org/lkml/2018/6/5/847

There is a number of ways to hack this particular case to work.

However, there is a more general problem with this. Some config options
may depend on the environment, may not be saved, and the environment is
not saved either.
Which environment variables in particular are in your mind?

As for ARCH, you need to pass the same ARCH as you used for building the kernel.
(For native building, you do not have to pass ARCH explicitly, though.)

As for CC, HOSTCC, etc.
yes, these are new 'unsaved' environments.

CONFIG options now depend on the compiler.
This is the concept suggested by Linus Torvalds.

So in the end all the infrastructure with symlinks
from module directory pointing to the kernel source and object
directory is useless. To interpret the config stored there you need the
environment and that is not saved anywhere. So if you try to build
out-of-tree module it might end up reconfiguring your kernel and
producing useless modules.
No. out-of-tree module building never ever re-configures the kernel.

out-of-tree modules are built with exactly the same configuration
as used for the kernel.


There is one more assumption here.

Greg-KH said:
  We don't ever support the system of loading a module built with anything
  other than the _exact_ same compiler than the kernel was.

(https://lkml.org/lkml/2017/10/4/496)



Based on that statement,
CONFIG options depending on 'CC' are valid for out-of-tree modules as well.



Is there any plan to fix this?

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help