[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220302015842.128491-1-zhuyan34@huawei.com>
Date: Wed, 2 Mar 2022 09:58:42 +0800
From: Yan Zhu <zhuyan34@...wei.com>
To: <mcgrof@...nel.org>
CC: <andrii@...nel.org>, <ast@...nel.org>, <bpf@...r.kernel.org>,
<daniel@...earbox.net>, <john.fastabend@...il.com>, <kafai@...com>,
<keescook@...omium.org>, <kpsingh@...nel.org>,
<linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<liucheng32@...wei.com>, <netdev@...r.kernel.org>,
<nixiaoming@...wei.com>, <songliubraving@...com>,
<xiechengliang1@...wei.com>, <yhs@...com>, <yzaikin@...gle.com>,
<zengweilin@...wei.com>, <zhuyan34@...wei.com>
Subject: Re: [PATCH v2 sysctl-next] bpf: move the bpf syscall sysctl table to bpf module
Mon, 28 Feb 2022 15:41:40 -0800, Luis Chamberlain wrote:
> On Mon, Feb 28, 2022 at 04:53:44PM +0100, Daniel Borkmann wrote:
> > Hi Yan,
> >
> > On 2/23/22 11:28 AM, Yan Zhu wrote:
> > > Aggregating the code of the feature in the code file of the feature
> > > itself can improve readability and reduce merge conflicts. So move
> > > the bpf syscall sysctl table to kernel/bpf/syscall.c
> > >
> > > Signed-off-by: Yan Zhu <zhuyan34@...wei.com>
> > >
> > > ---
> > > v1->v2:
> > > 1.Added patch branch identifier sysctl-next.
> > > 2.Re-describe the reason for the patch submission.
> >
> > I'm not applying it given there is very little value in this change, see also what
> > has been said earlier:
> >
> > https://lore.kernel.org/bpf/CAADnVQKmBoQEG1+nmrCg2ePVncn9rZJX9R4eucP9ULiY=xVGjQ@mail.gmail.com/
>
> Daniel,
>
> sorry folk are seing you patches with crap commit logs. The
> justification should be made clearer: we're moving sysctls out of
> kernel/sysctl.c as its a mess. I already moved all filesystem sysctls
> out. And with time the goal is to move all sysctls out to their own
> susbsystem/actual user.
> kernel/sysctl.c has grown to an insane mess and its easy to run
> into conflicts with it. The effort to move them out is part of this.
Luis,
Thanks for the suggestion, I will use it as my patch from the commit
message to be able to clearly describe the purpose of the patch.
> The commit logs should not suck though...
Powered by blists - more mailing lists