Messages in this thread | | | Date | Wed, 28 Sep 2022 15:52:13 +0800 | Subject | Re: [PATCH -next] init/Kconfig: fix unmet direct dependencies | From | Ren Zhijie <> |
| |
在 2022/9/28 15:20, Lukas Bulwahn 写道: > On Wed, Sep 28, 2022 at 9:01 AM Sebastian Andrzej Siewior > <bigeasy@linutronix.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.
My consider is that if CHECKPOINT_RESTORE depends on PROC_FS , when PROC_FS is not set the user have no chance to set it on.
Thanks,
Ren
> > 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 > . .
| |