On Thu, Oct 24, 2024 at 04:07:10PM +0800, yukaixiong wrote:
...
The patches in the sysctl subsys that allow you to qualify the ctl_table
Sorry, I don't understand what is the meaning of "create a dependencymm/swap.c | 16 ++-General comment for the patchset in general. I would consider making the
mm/swap.h | 1 +
mm/util.c | 67 +++++++--
mm/vmscan.c | 23 +++
mm/vmstat.c | 44 +++++-
net/sunrpc/auth.c | 2 +-
security/min_addr.c | 11 ++
23 files changed, 330 insertions(+), 312 deletions(-)
--
2.34.1
new sysctl tables const. There is an effort for doing this and it has
already lanted in linux-next. So if you base your patch from a recent
next release, then it should just work. If you *do* decide to add a
const qualifier, then note that you will create a dependency with the
sysctl patchset currently in next and that will have to go in before.
Best
with the sysctl patchset".
as const are not in mainline yet. They are in linux-next. This means
that if these patches go into the next kernel release before the
sysctl-next branch, it will have compilation errors. Therefore the
sysctl-next branch needs to be pulled in to the new kernel release
before this patchest. This also means that for this to build properly it
has to be based on a linux-next release.
Do you just want me to change all "static struct ctl_table" type tableYou should const qualify them if the maintainer that is pulling in these
into "static const struct ctl_table" type in my patchset?
patches is ok with it. You should *not* const qualify them if the
maintainer prefers otherwise.
Please get back to me if I did not address your questions.
Best