From: Petr Mladek <pmladek@suse.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: akpm@linux-foundation.org, keescook@chromium.org,
yzaikin@google.com, nixiaoming@huawei.com, ebiederm@xmission.com,
peterz@infradead.org, gregkh@linuxfoundation.org, pjt@google.com,
liu.hailong6@zte.com.cn, andriy.shevchenko@linux.intel.com,
sre@kernel.org, penguin-kernel@i-love.sakura.ne.jp,
senozhatsky@chromium.org, wangqing@vivo.com, bcrl@kvack.org,
viro@zeniv.linux.org.uk, jack@suse.cz, amir73il@gmail.com,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/9] sysctl: add a new register_sysctl_init() interface
Date: Thu, 25 Nov 2021 17:14:23 +0100 [thread overview]
Message-ID: <YZ+2XwgQn8UpVcpb@alley> (raw)
In-Reply-To: <20211123202347.818157-2-mcgrof@kernel.org>
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
next prev parent reply other threads:[~2021-11-25 16:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 20:23 [PATCH v2 0/9] sysctl: first set of kernel/sysctl cleanups Luis Chamberlain
2021-11-23 20:23 ` [PATCH v2 1/9] sysctl: add a new register_sysctl_init() interface Luis Chamberlain
2021-11-25 16:14 ` Petr Mladek [this message]
2021-11-29 21:01 ` Luis Chamberlain
2021-11-23 20:23 ` [PATCH v2 2/9] sysctl: Move some boundary constants from sysctl.c to sysctl_vals Luis Chamberlain
2021-11-24 4:51 ` Eric W. Biederman
2021-11-24 7:05 ` Xiaoming Ni
2021-11-24 17:38 ` Eric W. Biederman
2021-11-24 23:12 ` Luis Chamberlain
2021-11-23 20:23 ` [PATCH v2 3/9] hung_task: Move hung_task sysctl interface to hung_task.c Luis Chamberlain
2021-11-26 9:46 ` Petr Mladek
2021-11-23 20:23 ` [PATCH v2 4/9] watchdog: move watchdog sysctl interface to watchdog.c Luis Chamberlain
2021-11-26 9:40 ` Petr Mladek
2021-11-23 20:23 ` [PATCH v2 5/9] sysctl: make ngroups_max const Luis Chamberlain
2021-11-23 20:23 ` [PATCH v2 6/9] sysctl: use const for typically used max/min proc sysctls Luis Chamberlain
2021-11-23 20:23 ` [PATCH v2 7/9] sysctl: use SYSCTL_ZERO to replace some static int zero uses Luis Chamberlain
2021-11-23 20:23 ` [PATCH v2 8/9] aio: move aio sysctl to aio.c Luis Chamberlain
2021-11-24 9:32 ` Jan Kara
2021-11-23 20:23 ` [PATCH v2 9/9] dnotify: move dnotify sysctl to dnotify.c Luis Chamberlain
2021-11-24 9:31 ` Jan Kara
2021-11-24 0:14 ` [PATCH v2 0/9] sysctl: first set of kernel/sysctl cleanups Andrew Morton
2021-11-24 0:27 ` Luis Chamberlain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YZ+2XwgQn8UpVcpb@alley \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bcrl@kvack.org \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liu.hailong6@zte.com.cn \
--cc=mcgrof@kernel.org \
--cc=nixiaoming@huawei.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=senozhatsky@chromium.org \
--cc=sre@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wangqing@vivo.com \
--cc=yzaikin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).