Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp36949imm; Thu, 28 Jun 2018 13:25:27 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJo7mwoQAzGm4U9sWB/pXVBow3zXPKVgCfz5fvhDWyw3WJp12hx816XIflfzWPQ18Nn4PiU X-Received: by 2002:a17:902:42a3:: with SMTP id h32-v6mr11789427pld.72.1530217527596; Thu, 28 Jun 2018 13:25:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530217527; cv=none; d=google.com; s=arc-20160816; b=U3v4aXvSmlanpA1XINj8NL4LcLdQrkuUOVtiW3Utky5gs8ruumBTRsIaYGDAsBqtKI mnDLupg7OSrfLfemMiKtivUfOP3i8jVeHajUHkugjV/4++qKh169XE4dXZOnGdvpk+JD kEWuOLT/wMZFFZZtz+iK+Hm0/YxvmQfIqnMghK+iQ7bXa+ChlRn6f4MywzbjDpZvlovX mAUL7V/JUeDRsY7rEPmQ5On8GAkfdeFrgUjfhlfvavvsPZ8mRiqEjAraDjqH06fbQyNw fTrWb/RqFr70pKDxK+gZUOd8sFIFZr9BazZ2FKbfx9GFe8uHwTW1zuQGFzNjmdcrk4qJ pvHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=Bfx6wOpXIIvRSpWFEvPoq3jgLPLHSEFJFIkCtt+g2Fk=; b=pbuYFegc8K6aSwQUao0dpf/7CSmdij5oN7ZVowSZUevdUclA0l11IAeqwCjm7Cfd3V i1RuM24VdUBOgqFGK/ZiD+ecuW8DGMZlunS3tpIZTSTwmnSQFux/fFZ3VrN5RHGsq9/f DbkaEct0lfirSOU+T2zZ4dKsh6HQBzaTwEH10XVhRv+aeQbxuLNKwbnF+/A8Y9K301By Wfyu4JAhfxDpstFe01Jm0tlRTbJHgRIgDXb4uUmNLKxJPUOBYPmBu8izvDGuhYQPaJW0 xvBrp1pj94z9QAorEXyWhe4UXHtNX5oJQO/i60xapqpsoGobGWp3Vu6i6XzrjWyu6Cw0 oGig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z10-v6si3888783pgo.412.2018.06.28.13.25.13; Thu, 28 Jun 2018 13:25:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754722AbeF1TGY convert rfc822-to-8bit (ORCPT + 99 others); Thu, 28 Jun 2018 15:06:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:39506 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1030575AbeF1TDo (ORCPT ); Thu, 28 Jun 2018 15:03:44 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3187BAD4A; Thu, 28 Jun 2018 19:03:39 +0000 (UTC) Date: Thu, 28 Jun 2018 11:16:23 +0200 From: Michal =?UTF-8?B?U3VjaMOhbmVr?= To: Masahiro Yamada Cc: Linux Kernel Mailing List , Takashi Iwai , Andreas Schwab , Michal Kubecek , Michal Marek , Jonathan Corbet , Yoshinori Sato , Rich Felker , "David S. Miller" , Jeff Dike , Richard Weinberger , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , X86 ML , Kees Cook , Philippe Ombredanne , Greg Kroah-Hartman , Ulf Magnusson , Jeff Mahoney , "Peter Zijlstra," , Mathieu Desnoyers , Frederic Weisbecker , Randy Dunlap , Dominik Brodowski , Nicholas Piggin , Linux Kbuild mailing list , "open list:DOCUMENTATION" , Linux-sh list , sparclinux , linux-um@lists.infradead.org Subject: Re: due to kconfig changes kernel config file is no longer sufficient for configuring the kernel Message-ID: <20180628111623.3807fe9b@naga.suse.cz> In-Reply-To: References: <20180627143705.5a1fed1c@kitsune.suse.cz> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 27 Jun 2018 23:07:21 +0900 Masahiro Yamada wrote: > Hi. > > > 2018-06-27 21:37 GMT+09:00 Michal Suchánek : > > 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. This does not look like syntax only change to me: diff --git a/init/Kconfig b/init/Kconfig index 15aae32e0719..1217fc62ca61 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1,20 +1,12 @@ -config ARCH - string - option env="ARCH" - -config KERNELVERSION - string - option env="KERNELVERSION" - > > Unless I am missing something, > we have never saved ARCH in the .config in the past. There was a config symbol defined for it before the commit removed it. > > > > 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? Any that is used in Kconfig. > > 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.) Except if you do pass it to make config you may need to pass it to to make later as well. > > 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. It does implicitly because the config values depend on environment that is not saved and the values themselves are not saved either. If that happens to expose a new variable it is even explicitly reconfigured. > > out-of-tree modules are built with exactly the same configuration > as used for the kernel. It is not true. And that is the problem. You need the config file and dump of the environment passed to the make command at configuration time to get the exact same configuration. The environment is not saved anywhere, though. Thanks Michal