[lkml]   [2018]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/5] sysctl: Enable easy addition of range showing sysctl parameters
On Wed,  7 Mar 2018 15:34:24 -0500 Waiman Long <> wrote:

> This patch series is to be applied on top of the patch
> series "ipc: Clamp *mni to the real IPCMNI limit"
> (
> 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>

 \ /
  Last update: 2018-03-07 23:48    [W:0.054 / U:2.684 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site