Automagic SYSCTLs

mdf at FreeBSD.org mdf at FreeBSD.org
Sun Jan 16 05:35:54 UTC 2011


On Sat, Jan 15, 2011 at 5:10 PM, Garrett Cooper <gcooper at freebsd.org> wrote:
> On Sat, Jan 15, 2011 at 4:12 PM,  <mdf at freebsd.org> wrote:
>> I started out with a plan to import a patch from Isilon that adds
>> type-safety to the existing SYSCTLs for scalar variables in the
>> kernel.  After the discussion on the svn mailing list here
>> (http://lists.freebsd.org/pipermail/svn-src-head/2011-January/024097.html)
>> I now have a prototype patch for SYSCTL_ADD_SCALAR that could replace
>> most uses of SYSCTL_ADD_{INT, UINT, LONG, ULONG, QUAD} and is suitable
>> for the SYSCTL_ADD_FOO that are used on 16 and 8 bit members (without
>> type checking) today.
>>
>> The gist is that the handler knows the sizeof the variable in the
>> kernel and uses this to copy out.  For the case of a long, there's
>> some goop for SCTL_MASK32.  For the case of 8 and 16 bit variables,
>> they are still copied in and out as 32-bit quantities.
>>
>> Let me know if this seems like the right or wrong direction in which
>> to move.  I haven't tackled the static sysctls as the code I have does
>> some run-time evaluation because the code is easier to write that way.
>>  One possibility is to change the sysctl_oid struct or at least add a
>> SIGNED flag; this would also have the advantage of making it possible
>> to clean up the CTLTYPE_[U]INT issue where there is no real difference
>> between the two CTLTYPEs.
>>
>> http://people.freebsd.org/~mdf/bsd-sysctl-scalar.diff
>
> Looks interesting, but what are the performance implications of the new logic?

I guess I'm not quite sure how to answer this.  The add should be
about the same, and it's only done once at kernel or driver init.  The
handler time is essentially meaningless since even reading the value
using sysctl(8) will take the SYSCTL lock several times, and doing a
write will take it quite a few more.

Thanks,
matthew


More information about the freebsd-arch mailing list