Re: [PATCH 0/5] sysctl: Enable easy addition of range showing sysctl parameters

[Andrew Morton]

On Wed,  7 Mar 2018 15:34:24 -0500 Waiman Long <longman@xxxxxxxxxx> wrote:

> This patch series is to be applied on top of the patch
> series "ipc: Clamp *mni to the real IPCMNI limit"
> (https://lkml.org/lkml/2018/3/1/716).
> 
> The purpose of this patch series is to enable easy addition of new
> auxillary sysctl parameters that can be read to display ranges of
> other sysctl parameters they are associated with.
> 
> With this patch series applied, a developer can add a range-showing
> auxillary sysctl entries by just setting the CTL_FLAGS_SHOW_RANGE
> flag in the ctl_table entry that has a range to show and add one more
> to the number of reserved range entries in the CTL_RESERVE_RANGES()
> macro before the terminating null entry. The new auxillary sysctl
> parameters will have the "_range" suffix added.
> 
> The number of ctl_table entries that have the CTL_FLAGS_SHOW_RANGE flag
> should match the number of reserved entries in the CTL_RESERVE_RANGES()
> macro. Otherwise, warning or error like below will be logged in the
> kernel ring buffer.
> 
>   Warning: Too many reserved ctl_table range entries ("shmmax")!
> 
>   Error: Insufficient reserved ctl_table range entries ("shmmax")!
> 
> The IPC sysctl parameters msgmni and shmmni are extended to have
> those auxillary sysctl entries. As a result, one can now find out
> the range of allowable value by looking at the corresponding
> auxillary _range sysctl parameters. For example,
> 
>   % cat msgmni_range
>   [0, 32768]
> 
> That means the msgmni sysctl parameter has to be within the 0 - 32768
> range inclusively.
> 
> ...
> 
>  fs/proc/proc_sysctl.c  | 99 +++++++++++++++++++++++++++++++++++++++++++++++---
>  include/linux/sysctl.h | 52 +++++++++++++++++++++++++-
>  ipc/ipc_sysctl.c       |  5 ++-
>  kernel/sysctl.c        | 91 ++++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 238 insertions(+), 9 deletions(-)

That quite a bunch of new code and it's not clear to me that we get a
lot of value from it all.  Perhaps I'm missing the point.

A worked example would help, along the lines of:


a) Here's how we do X at present and here's the output

b) Here's how we X after these patches and here's the new output

c) b) is better than a) for <reasons>