[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <boris.20210215155804@codesynthesis.com>
Date: Mon, 15 Feb 2021 16:13:28 +0200
From: Boris Kolpackov <boris@...esynthesis.com>
To: Mickaël Salaün <mic@...ikod.net>
Cc: James Morris <jmorris@...ei.org>,
Masahiro Yamada <masahiroy@...nel.org>,
"Serge E . Hallyn" <serge@...lyn.com>,
Casey Schaufler <casey@...aufler-ca.com>,
Nicolas Iooss <nicolas.iooss@....org>,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
Mickaël Salaün <mic@...ux.microsoft.com>
Subject: Re: [PATCH v1 2/3] kconfig: Ask user if string needs to be changed
when dependency changed
Mickaël Salaün <mic@...ikod.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?
Powered by blists - more mailing lists