Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 15 Feb 2021 16:13:28 +0200
From:   Boris Kolpackov <boris@codesynthesis.com>
To:     =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= <mic@digikod.net>
Cc:     James Morris <jmorris@namei.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        "Serge E . Hallyn" <serge@hallyn.com>,
        Casey Schaufler <casey@schaufler-ca.com>,
        Nicolas Iooss <nicolas.iooss@m4x.org>,
        linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= <mic@linux.microsoft.com>
Subject: Re: [PATCH v1 2/3] kconfig: Ask user if string needs to be changed
 when dependency changed
Message-ID: <boris.20210215155804@codesynthesis.com>
References: <20210215122513.1773897-1-mic@digikod.net>
 <20210215122513.1773897-3-mic@digikod.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210215122513.1773897-3-mic@digikod.net>
Organization: Code Synthesis
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk

Micka?l Sala?n <mic@digikod.net> writes:

> Content of string configuration may depend on related kernel
> configurations.  Modify oldconfig and syncconfig to inform users about
> possible required configuration update and give them the opportunity to
> update it:
> * if dependencies of this string has changed (e.g. enabled or disabled),
> * and if the current value of this string is different than the (new)
>   default one.

I have a number of questions:

1. Why is a change in dependencies necessarily means that the dependent's
   value must be revised? Here is a specific example (to make sure we are
   talking about the same things):

   config FOO
     string "Foo value"
     depends on BAR || BAZ

   Why, in the general case, when I disable BAR and enable BAZ I must
   also revise the value of FOO?

2. How do you know that what's in the user's .config is the old default
   and in Kconfig -- the new default value? What if in the user's .config
   is a custom value (with which the user is perfectly happy) and what's
   in Kconfig is the old default (which the user has already seen)?

3. Why limit this to strings only?


> This is particularly relevant for CONFIG_LSM which contains a list of
> LSMs enabled at boot, but users will not have a chance to update this
> list with a make oldconfig.

If my understanding above is correct, this feels like it's been purpose-
made to address whatever issue you are having with CONFIG_LSM. If so,
what about potential numerous other options that don't have this issue
but will now be presented to the user for modification?