[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKXUXMxGt9UGhw9Ap_M3U2AF1vw2dX7WpDO71=UwV0Be3t4sNw@mail.gmail.com>
Date: Wed, 28 Sep 2022 09:20:42 +0200
From: Lukas Bulwahn <lukas.bulwahn@...il.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Ren Zhijie <renzhijie2@...wei.com>, akpm@...ux-foundation.org,
ndesaulniers@...gle.com, nathan@...nel.org, vbabka@...e.cz,
masahiroy@...nel.org, arnd@...db.de, seanjc@...gle.com,
hannes@...xchg.org, ojeda@...nel.org, mhiramat@...nel.org,
dmitry.torokhov@...il.com, atomlin@...hat.com, ddiss@...e.de,
christophe.leroy@...roup.eu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next] init/Kconfig: fix unmet direct dependencies
On Wed, Sep 28, 2022 at 9:01 AM Sebastian Andrzej Siewior
<bigeasy@...utronix.de> wrote:
>
> On 2022-09-28 06:49:34 [+0000], Ren Zhijie wrote:
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -1273,6 +1273,7 @@ endif # NAMESPACES
> >
> > config CHECKPOINT_RESTORE
> > bool "Checkpoint/restore support"
> > + select PROC_FS
>
> Couldn't this become a depends?
>
It could also be a depends (to resolve the warning).
It is just the question whether:
When PROC_FS is not set, should the CHECKPOINT_RESTORE still be
visible as a config option to add (and then automatically add
PROC_FS)? Then select is right here.
or:
When PROC_FS is not set, should the CHECKPOINT_RESTORE not be visible
as a config option to add? Instead the user first needs to add
PROC_FS, then CHECKPOINT_RESTORE becomes visible as an option to add,
and then the user can add it. Then depends would be right.
For me, both seem reasonable. So, I assume Ren considered select the
better choice.
But maybe Ren can confirm.
A kernel build configuration without PROC_FS is quite special
anyway... and then being interested in CHECKPOINT_ RESTORE for such a
system is really really special. I wonder if that user then really
knows what he or she is configuring at that point.
Lukas
Powered by blists - more mailing lists