RFC: sysctl additional functions/macros
Julian Elischer
julian at elischer.org
Thu Jan 3 18:27:29 PST 2008
Alfred Perlstein wrote:
> Yes, but EINVAL please.
I wondered who would be the first to complain about that..
"Gee you Juniper people have no sense of humour" :-) :-)
>
> Another idea would be a simplified SYSCTL_INT_PROC
> that allowed one to define a function like so:
>
> int
> sysctl_handle_int_proc(void *handle, int *newval, int *max, int *min)
> {
>
>
> }
>
> If this function returned '0' then 'newval' would be accepted.
> Otherwise the function should return an error, most likely EINVAL.
>
> The point being that a lot of these maximums may take a calculation
> and we should make it as easy as possible to do this calculation
> and provide the function for doing so.
>
> One would also set the min/max values so that one could query
> the acceptable bounds of a tunable, or even the bounds of of
> the tuneable.
>
> (Note: if *newval == NULL, we're just querying max/min, not
> doing a set operation.)
>
> (Note 2: "handle" is so you can have a common handler and
> possibly switch() off of handle for multiple sysctl ints to
> reduce the number of functions required.)
>
> -Alfred
>
> * Julian Elischer <julian at elischer.org> [080103 17:57] wrote:
>> I would like to extend the current SYSCTL_INT() with
>> SYSCTL_INT_CLAMPED() or similar, where you also supply a
>> maximum acceptable value. (and maybe a clue as to what to say if it is
>> a bad value).
>>
>> so many users of SYSCTL_INT don't check for bad values because it's so
>> much harder (you need to supply your own handler), and so many
>> simple handlers exist fo rthe people that DO check that it seems to
>> me that we should provide a pre-canned way to do this....
>>
>> we are limited to using the existing structure,
>> but as we have no existing callers we can redefine
>> one element....
>>
>> I would suggest:
>>
>> I'd like to test for a minimum too but I think I can only squeeze one
>> field out of the existing struct sysctl_oid.
>>
>> SYSCTL_INT_CLAMPED(parent, nbr, name, access, ptr, max, descr)
>> ^^^^
>>
>> anyone think it's a bad idea?
>> After all the macros are evaluated, (etc.) it would call:
>> ( off the top of my head )
>>
>> int
>> sysctl_handle_int_max(SYSCTL_HANDLER_ARGS)
>> {
>> int error = 0;
>>
>> error = SYSCTL_OUT(req, arg1, sizeof(int));
>>
>> if (error || !req->newptr)
>> return (error);
>>
>> if (*(int *)arg1 > (int)arg2)
>> error = EDOOFUS;
>> else
>> error = SYSCTL_IN(req, arg1, sizeof(int));
>> return (error);
>> }
>> _______________________________________________
>> freebsd-arch at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>
More information about the freebsd-arch
mailing list