Messages in this thread | | | Date | Thu, 25 Nov 2021 17:14:23 +0100 | From | Petr Mladek <> | Subject | Re: [PATCH v2 1/9] sysctl: add a new register_sysctl_init() interface |
| |
On Tue 2021-11-23 12:23:39, Luis Chamberlain wrote: > From: Xiaoming Ni <nixiaoming@huawei.com> > > The kernel/sysctl.c is a kitchen sink where everyone leaves > their dirty dishes, this makes it very difficult to maintain. > > To help with this maintenance let's start by moving sysctls to > places where they actually belong. The proc sysctl maintainers > do not want to know what sysctl knobs you wish to add for your own > piece of code, we just care about the core logic. > > Today though folks heavily rely on tables on kernel/sysctl.c so > they can easily just extend this table with their needed sysctls. > In order to help users move their sysctls out we need to provide a > helper which can be used during code initialization. > > We special-case the initialization use of register_sysctl() since > it *is* safe to fail, given all that sysctls do is provide a dynamic > interface to query or modify at runtime an existing variable. So the > use case of register_sysctl() on init should *not* stop if the sysctls > don't end up getting registered. It would be counter productive to > stop boot if a simple sysctl registration failed. > > Provide a helper for init then, and document the recommended init > levels to use for callers of this routine. We will later use this > in subsequent patches to start slimming down kernel/sysctl.c tables > and moving sysctl registration to the code which actually needs > these sysctls.
Do we really need a new helper for this? Is the failure acceptable only during system initialization?
The warning would be useful even for the original register_sysctl().
It should be up-to-the caller to decide if the failure is fatal or not. It might be enough to document the reasoning why a warning is enough in most cases.
Best Regards, Petr
| |