Sysctl table is easier to read under its own module.
Signed-off-by: Yan Zhu <redacted>
---
kernel/bpf/syscall.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 71 ----------------------------------------------
2 files changed, 80 insertions(+), 71 deletions(-)
From: Luis Chamberlain <mcgrof@kernel.org> Date: 2022-02-23 01:42:37
On Wed, Feb 23, 2022 at 09:35:29AM +0800, Yan Zhu wrote:
Sysctl table is easier to read under its own module.
Hey Yan, thanks for you patch!
This does not explain how this is being to help with maitenance as
otherwise this makes kernel/sysctl.c hard to maintain and we also
tend to get many conflicts. It also does not explain how all the
filesystem sysctls are not gone and that this is just the next step,
moving slowly the rest of the sysctls. Explaining this in the commit
log will help patch review and subsystem maintainers understand the
conext / logic behind the move.
Signed-off-by: Yan Zhu <redacted>
I'd be more than happy to take this if bpf folks Ack. To avoid conflicts
I can route this through sysctl-next which is put forward in particular
to avoid conflicts across trees for this effort. Let me know.
Luis
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 <redacted>
---
v1->v2:
1.Added patch branch identifier sysctl-next.
2.Re-describe the reason for the patch submission.
---
kernel/bpf/syscall.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 71 ----------------------------------------------
2 files changed, 80 insertions(+), 71 deletions(-)
From: Daniel Borkmann <daniel@iogearbox.net> Date: 2022-02-28 16:10:08
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 <redacted>
---
v1->v2:
1.Added patch branch identifier sysctl-next.
2.Re-describe the reason for the patch submission.
From: Luis Chamberlain <mcgrof@kernel.org> Date: 2022-02-28 23:41:51
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:
quoted
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 <redacted>
---
v1->v2:
1.Added patch branch identifier sysctl-next.
2.Re-describe the reason for the patch submission.
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.
The commit logs should not suck though...
Luis
Mon, 28 Feb 2022 15:41:40 -0800, Luis Chamberlain wrote:
On Mon, Feb 28, 2022 at 04:53:44PM +0100, Daniel Borkmann wrote:
quoted
Hi Yan,
On 2/23/22 11:28 AM, Yan Zhu wrote:
quoted
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 <redacted>
---
v1->v2:
1.Added patch branch identifier sysctl-next.
2.Re-describe the reason for the patch submission.
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.
We're moving sysctls out of kernel/sysctl.c as its a mess. We
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.
Signed-off-by: Yan Zhu <redacted>
---
v1->v2:
1.Added patch branch identifier sysctl-next.
2.Re-describe the reason for the patch submission.
v2->v3:
Re-describe the reason for the patch submission.
---
kernel/bpf/syscall.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 71 ----------------------------------------------
2 files changed, 80 insertions(+), 71 deletions(-)
From: Luis Chamberlain <mcgrof@kernel.org> Date: 2022-03-02 20:39:15
On Wed, Mar 02, 2022 at 10:04:12AM +0800, Yan Zhu wrote:
We're moving sysctls out of kernel/sysctl.c as its a mess. We
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.
Signed-off-by: Yan Zhu <redacted>
Daniel, let me know if this makes more sense now, and if so I can
offer take it through sysctl-next to avoid conflicts more sysctl knobs
get moved out from kernel/sysctl.c.
Luis
From: Daniel Borkmann <daniel@iogearbox.net> Date: 2022-03-03 23:45:02
On 3/2/22 9:39 PM, Luis Chamberlain wrote:
On Wed, Mar 02, 2022 at 10:04:12AM +0800, Yan Zhu wrote:
quoted
We're moving sysctls out of kernel/sysctl.c as its a mess. We
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.
Signed-off-by: Yan Zhu <redacted>
Daniel, let me know if this makes more sense now, and if so I can
offer take it through sysctl-next to avoid conflicts more sysctl knobs
get moved out from kernel/sysctl.c.
If this is a whole ongoing effort rather than drive-by patch, then it's
fine with me. Btw, the patch itself should also drop the linux/bpf.h
include from kernel/sysctl.c since nothing else is using it after the
patch.
Btw, related to cleanups.. historically, we have a bunch of other knobs
for BPF under net (in net_core_table), that is:
/proc/sys/net/core/bpf_jit_enable
/proc/sys/net/core/bpf_jit_harden
/proc/sys/net/core/bpf_jit_kallsyms
/proc/sys/net/core/bpf_jit_limit
Would be nice to consolidate all under e.g. /proc/sys/kernel/bpf_* for
future going forward, and technically, they should be usable also w/o
net configured into kernel. Is there infra to point the sysctl knobs
e.g. under net/core/ to kernel/, or best way would be to have single
struct ctl_table and register for both?
Cheers,
Daniel
From: Luis Chamberlain <mcgrof@kernel.org> Date: 2022-03-04 00:23:42
On Fri, Mar 04, 2022 at 12:44:48AM +0100, Daniel Borkmann wrote:
On 3/2/22 9:39 PM, Luis Chamberlain wrote:
quoted
On Wed, Mar 02, 2022 at 10:04:12AM +0800, Yan Zhu wrote:
quoted
We're moving sysctls out of kernel/sysctl.c as its a mess. We
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.
Signed-off-by: Yan Zhu <redacted>
Daniel, let me know if this makes more sense now, and if so I can
offer take it through sysctl-next to avoid conflicts more sysctl knobs
get moved out from kernel/sysctl.c.
If this is a whole ongoing effort rather than drive-by patch,
It is ongoing effort, but it will take many releases before we tidy
this whole thing up.
then it's
fine with me.
OK great. Thanks for understanding the mess.
Btw, the patch itself should also drop the linux/bpf.h
include from kernel/sysctl.c since nothing else is using it after the
patch.
I'll let Yan deal with that.
Btw, related to cleanups.. historically, we have a bunch of other knobs
for BPF under net (in net_core_table), that is:
/proc/sys/net/core/bpf_jit_enable
/proc/sys/net/core/bpf_jit_harden
/proc/sys/net/core/bpf_jit_kallsyms
/proc/sys/net/core/bpf_jit_limit
Would be nice to consolidate all under e.g. /proc/sys/kernel/bpf_* for
Oh the actual "name" / directory location is not changing.
What changes is just where in code you declare them.
future going forward, and technically, they should be usable also w/o
net configured into kernel.
That's up to you, and just consider if you have scrupts using these
already. You may need backward compatibility. You don't need networking
to create the net directory for sysctls too. The first sysctl to create
the directory creates it, if its not created, it will be created.
Is there infra to point the sysctl knobs
e.g. under net/core/ to kernel/, or best way would be to have single
struct ctl_table and register for both?
From: Luis Chamberlain <mcgrof@kernel.org> Date: 2022-04-06 22:41:37
On Thu, Mar 03, 2022 at 04:23:26PM -0800, Luis Chamberlain wrote:
On Fri, Mar 04, 2022 at 12:44:48AM +0100, Daniel Borkmann wrote:
quoted
On 3/2/22 9:39 PM, Luis Chamberlain wrote:
quoted
On Wed, Mar 02, 2022 at 10:04:12AM +0800, Yan Zhu wrote:
quoted
We're moving sysctls out of kernel/sysctl.c as its a mess. We
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.
Signed-off-by: Yan Zhu <redacted>
Daniel, let me know if this makes more sense now, and if so I can
offer take it through sysctl-next to avoid conflicts more sysctl knobs
get moved out from kernel/sysctl.c.
If this is a whole ongoing effort rather than drive-by patch,
It is ongoing effort, but it will take many releases before we tidy
this whole thing up.
quoted
then it's
fine with me.
OK great. Thanks for understanding the mess.
quoted
Btw, the patch itself should also drop the linux/bpf.h
include from kernel/sysctl.c since nothing else is using it after the
patch.
We're moving sysctls out of kernel/sysctl.c as its a mess. We
already moved all filesystem sysctls out. And with time the goal is
to move all sysctls out to their own subsystem/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.
Signed-off-by: Yan Zhu <redacted>
---
v1->v2:
1.Added patch branch identifier sysctl-next.
2.Re-describe the reason for the patch submission.
v2->v3:
Re-describe the reason for the patch submission.
v3->v4:
1.Remove '#include <linux/bpf.h>' in kernel/sysctl.c
2.re-adaptive the patch
---
kernel/bpf/syscall.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 79 -----------------------------------------------
2 files changed, 87 insertions(+), 79 deletions(-)
From: Daniel Borkmann <daniel@iogearbox.net> Date: 2022-04-13 14:45:44
On 4/7/22 9:07 AM, Yan Zhu wrote:
We're moving sysctls out of kernel/sysctl.c as its a mess. We
already moved all filesystem sysctls out. And with time the goal is
to move all sysctls out to their own subsystem/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.
Signed-off-by: Yan Zhu <redacted>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Given the desire is to route this via sysctl-next and we're not shortly
before but after the merge win, could we get a feature branch for bpf-next
to pull from to avoid conflicts with ongoing development cycle?
Thanks,
Daniel
From: Luis Chamberlain <mcgrof@kernel.org> Date: 2022-04-13 19:00:50
On Wed, Apr 13, 2022 at 04:45:00PM +0200, Daniel Borkmann wrote:
On 4/7/22 9:07 AM, Yan Zhu wrote:
quoted
We're moving sysctls out of kernel/sysctl.c as its a mess. We
already moved all filesystem sysctls out. And with time the goal is
to move all sysctls out to their own subsystem/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.
Signed-off-by: Yan Zhu <redacted>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Given the desire is to route this via sysctl-next and we're not shortly
before but after the merge win, could we get a feature branch for bpf-next
to pull from to avoid conflicts with ongoing development cycle?
Sure thing. So I've never done this sort of thing, so forgive me for
being new at it. Would it make sense to merge this change to sysctl-next
as-is today and put a frozen branch sysclt-next-bpf to reflect this,
which bpf-next can merge. And then sysctl-next just continues to chug on
its own? As-is my goal is to keep sysctl-next as immutable as well.
Or is there a better approach you can recommend?
Luis
From: Daniel Borkmann <daniel@iogearbox.net> Date: 2022-04-13 19:41:18
On 4/13/22 9:00 PM, Luis Chamberlain wrote:
On Wed, Apr 13, 2022 at 04:45:00PM +0200, Daniel Borkmann wrote:
quoted
On 4/7/22 9:07 AM, Yan Zhu wrote:
quoted
We're moving sysctls out of kernel/sysctl.c as its a mess. We
already moved all filesystem sysctls out. And with time the goal is
to move all sysctls out to their own subsystem/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.
Signed-off-by: Yan Zhu <redacted>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Given the desire is to route this via sysctl-next and we're not shortly
before but after the merge win, could we get a feature branch for bpf-next
to pull from to avoid conflicts with ongoing development cycle?
Sure thing. So I've never done this sort of thing, so forgive me for
being new at it. Would it make sense to merge this change to sysctl-next
as-is today and put a frozen branch sysclt-next-bpf to reflect this,
which bpf-next can merge. And then sysctl-next just continues to chug on
its own? As-is my goal is to keep sysctl-next as immutable as well.
Or is there a better approach you can recommend?
From: Luis Chamberlain <mcgrof@kernel.org> Date: 2022-04-13 19:46:22
On Wed, Apr 13, 2022 at 09:40:58PM +0200, Daniel Borkmann wrote:
On 4/13/22 9:00 PM, Luis Chamberlain wrote:
quoted
On Wed, Apr 13, 2022 at 04:45:00PM +0200, Daniel Borkmann wrote:
quoted
On 4/7/22 9:07 AM, Yan Zhu wrote:
quoted
We're moving sysctls out of kernel/sysctl.c as its a mess. We
already moved all filesystem sysctls out. And with time the goal is
to move all sysctls out to their own subsystem/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.
Signed-off-by: Yan Zhu <redacted>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Given the desire is to route this via sysctl-next and we're not shortly
before but after the merge win, could we get a feature branch for bpf-next
to pull from to avoid conflicts with ongoing development cycle?
Sure thing. So I've never done this sort of thing, so forgive me for
being new at it. Would it make sense to merge this change to sysctl-next
as-is today and put a frozen branch sysclt-next-bpf to reflect this,
which bpf-next can merge. And then sysctl-next just continues to chug on
its own? As-is my goal is to keep sysctl-next as immutable as well.
Or is there a better approach you can recommend?
From: Daniel Borkmann <daniel@iogearbox.net> Date: 2022-04-13 20:07:52
On 4/13/22 9:46 PM, Luis Chamberlain wrote:
On Wed, Apr 13, 2022 at 09:40:58PM +0200, Daniel Borkmann wrote:
quoted
On 4/13/22 9:00 PM, Luis Chamberlain wrote:
quoted
On Wed, Apr 13, 2022 at 04:45:00PM +0200, Daniel Borkmann wrote:
quoted
On 4/7/22 9:07 AM, Yan Zhu wrote:
quoted
We're moving sysctls out of kernel/sysctl.c as its a mess. We
already moved all filesystem sysctls out. And with time the goal is
to move all sysctls out to their own subsystem/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.
Signed-off-by: Yan Zhu <redacted>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Given the desire is to route this via sysctl-next and we're not shortly
before but after the merge win, could we get a feature branch for bpf-next
to pull from to avoid conflicts with ongoing development cycle?
Sure thing. So I've never done this sort of thing, so forgive me for
being new at it. Would it make sense to merge this change to sysctl-next
as-is today and put a frozen branch sysclt-next-bpf to reflect this,
which bpf-next can merge. And then sysctl-next just continues to chug on
its own? As-is my goal is to keep sysctl-next as immutable as well.
Or is there a better approach you can recommend?