[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200515202126.GY11244@42.do-not-panic.com>
Date: Fri, 15 May 2020 20:21:26 +0000
From: Luis Chamberlain <mcgrof@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: Xiaoming Ni <nixiaoming@...wei.com>, yzaikin@...gle.com,
adobriyan@...il.com, mingo@...nel.org, peterz@...radead.org,
akpm@...ux-foundation.org, yamada.masahiro@...ionext.com,
bauerman@...ux.ibm.com, gregkh@...uxfoundation.org,
skhan@...uxfoundation.org, dvyukov@...gle.com,
svens@...ckframe.org, joel@...lfernandes.org, tglx@...utronix.de,
Jisheng.Zhang@...aptics.com, pmladek@...e.com,
bigeasy@...utronix.de, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, wangle6@...wei.com
Subject: Re: [PATCH 1/4] hung_task: Move hung_task sysctl interface to
hung_task_sysctl.c
On Fri, May 15, 2020 at 09:03:54AM -0700, Kees Cook wrote:
> On Fri, May 15, 2020 at 04:56:34PM +0800, Xiaoming Ni wrote:
> > On 2020/5/15 16:04, Kees Cook wrote:
> > > On Fri, May 15, 2020 at 12:33:41PM +0800, Xiaoming Ni wrote:
> > > > Move hung_task sysctl interface to hung_task_sysctl.c.
> > > > Use register_sysctl() to register the sysctl interface to avoid
> > > > merge conflicts when different features modify sysctl.c at the same time.
> > > >
> > > > Signed-off-by: Xiaoming Ni <nixiaoming@...wei.com>
> > > > ---
> > > > include/linux/sched/sysctl.h | 8 +----
> > > > kernel/Makefile | 4 ++-
> > > > kernel/hung_task.c | 6 ++--
> > > > kernel/hung_task.h | 21 ++++++++++++
> > > > kernel/hung_task_sysctl.c | 80 ++++++++++++++++++++++++++++++++++++++++++++
> > >
> > > Why a separate file? That ends up needing changes to Makefile, the
> > > creation of a new header file, etc. Why not just put it all into
> > > hung_task.c directly?
> > >
> > > -Kees
> > >
> > But Luis Chamberlain's suggestion is to put the hung_task sysctl code in a
> > separate file. Details are in https://lkml.org/lkml/2020/5/13/762.
> > I am a little confused, not sure which way is better.
>
> Ah, yes, I see now. Luis, I disagree with your recommendation here -- I
> think complicating the Makefile is much less intuitive than just
> wrapping this code in an #ifdef block in the existing .c file.
That's fine, sorry for the trouble Xiaoming.
Luis
Powered by blists - more mailing lists