do we have a generic string-number sysctl mapping library ?
John Baldwin
jhb at freebsd.org
Fri Jun 27 15:51:36 UTC 2014
On Friday, June 27, 2014 5:14:59 am Luigi Rizzo wrote:
> Hi,
> I have frequently found myself using sysctls to control some kernel
> feature where a string would be a better (and sometimes the only)
> option than using a numeric value, yet the internal representation
> should be numeric for speed and robustness.
> Examples are the kern.timecounter, the default scheduler in dummynet,
> and now in netmap the selection between native and emulated mode.
> I am sure many of you can come up with other cases.
>
> I wonder if we have some support for that already in the sysctl code,
> or i should build a generic one next time i need to do that.
>
> Feel free to criticise the approach and suggest better ones.
> Right now i am using sysctls because i have a set of macros
> and wrapper functions that let me convert them to sysfs
> entries when building kernel code on linux, so I have a
> portable solutions.
>
> For the details, I'd like to have a mechanism that requires the
> kernel programmer supply a (possibly extensible) table of
> supported values, and matching constants to be used within
> the kernel. A single declaration should generate entries
> to get/set the current value as well as list options.
> We can discuss frills (such as wildcards, multiple values,etc).
I am not aware of such a beast. Even just supporting a simple table to map
labels to indices would be nice and would handle many cases. I.e. if you
had something like:
struct sysctl_table vals[] = {
"foo", (void *)1,
"bar", (void *)2,
NULL, NULL
};
static int myval;
static int
my_sysctl(SYSCTL_HANDLER_ARGS)
{
void *val;
int error;
val = (void *)myval;
error = sysctl_handle_table(oidp, vals, &val, req);
if (error || req->newptr == NULL)
return (error);
myval = (intptr_t)val;
return (0);
}
sysctl_handle_table() would use the initial value to find a suitable string
from the table for the "old" string, etc. Using void * for the value would
let you store arbitrary data, etc.
--
John Baldwin
More information about the freebsd-current
mailing list