[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80e800b505adf8a26b2ed9898d03516263a830a7.camel@perches.com>
Date: Mon, 06 Dec 2021 17:50:19 -0800
From: Joe Perches <joe@...ches.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
Xiaoming Ni <nixiaoming@...wei.com>,
Julia Lawall <Julia.Lawall@...ia.fr>, cocci@...ia.fr
Cc: linux-kernel@...r.kernel.org, mcgrof@...nel.org,
viro@...iv.linux.org.uk, ebiederm@...ssion.com,
keescook@...omium.org, jlayton@...nel.org, bfields@...ldses.org,
yzaikin@...gle.com, wangle6@...wei.com
Subject: Re: [PATCH] sysctl: Add a group of macro functions to initcall the
sysctl table of each feature
On Mon, 2021-12-06 at 17:38 -0800, Andrew Morton wrote:
> On Tue, 7 Dec 2021 09:13:20 +0800 Xiaoming Ni <nixiaoming@...wei.com> wrote:
>
> > To avoid duplicated code, add a set of macro functions to initialize the
> > sysctl table for each feature.
> >
> > The system initialization process is as follows:
> >
> > start_kernel () {
> > ...
> > /* init proc and sysctl base,
> > * proc_root_init()-->proc_sys_init()-->sysctl_init_bases()
> > */
> > proc_root_init(); /* init proc and sysctl base */
> > ...
> > arch_call_rest_init();
> > }
> >
> > arch_call_rest_init()-->rest_init()-->kernel_init()
> > kernel_init() {
> > ...
> > kernel_init_freeable(); /* do all initcalls */
> > ...
> > do_sysctl_args(); /* Process the sysctl parameter: sysctl.*= */
> > }
> >
> > kernel_init_freeable()--->do_basic_setup()-->do_initcalls()
> > do_initcalls() {
> > for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++) {
> > do_initcall_level
> > }
> >
> > The sysctl interface of each subfeature should be registered after
> > sysctl_init_bases() and before do_sysctl_args(). It seems that the sysctl
> > interface does not depend on initcall_levels. To prevent the sysctl
> > interface from being initialized before the feature itself. The
> > lowest-level late_initcall() is used as the common sysctl interface
> > registration level.
>
> I'm not normally a fan of wrapping commonly-used code sequences into
> magical macros, but this one does seem to make sense.
>
> I wonder if it is possible to cook up a checkpatch rule to tell people
> to henceforth use the magic macros rather than to open-code things in
> the old way. Sounds hard.
Almost impossible for checkpatch.
Likely easier in coccinelle.
Powered by blists - more mailing lists