Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 9 Nov 1995 06:17:51 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, phk@critter.tfs.com
Subject:   Re: cvs commit: src/sys/kern kern_sysctl.c
Message-ID:  <199511081917.GAA05935@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>Bruce I share most of your concerns, but disagree on the cure.

>Some specifics:

>Yes, I rely on compiler magic for the sysctl variables.  I live in the
>nineties, and we have to move forward.  I looked at other options, and
>they were uglier.

Linker sets are very old technology.  They are useful for static linking
and configuration, but we're trying to get away from those.  Consider an
lkm that adds some sysctls.  Linker sets are no help.  First, they can't
work for dynamic linking because the vectors are statically allocated
and can't be extended.  Second, if they could be extended, then you
would have to process them every time items are added or removed.
Current processing consists of sorting the vectors and probably only
works once (later, there may be pointers into the vectors...).  I
think it is better for the primitive operations to be addition and
removal operations on a tree.  The `sysctl_' linker set would just
give a list of things to be added to the tree initially.

More importantly, the current implementation makes it very difficult
for an lkm (or a syscall) to add sysctl variables.  E.g., changing
CPU_MAXID requires recompiling; if CPU_MAXID was made a little
larger to allow for more variables, the variable numbers would have
to be allocated at compile time so that they aren't ambiguous.

>I have included a string for description of the variables, which is
>presently not instatiated in the kernel.  My idea was to have a program
>do a 
>	find /usr/src/sys -type f -print | xargs gronk_out_sysctl_info > foo
>and proceed from there.

>It is overkill to expand the (possibly rather lengthy) descriptions into
>the kernel unless we want to have them available in the user-config, and
>the descriptions belong in the source, with the definition of the variable.

My binding operation could keep strings outside of the kernel if space is
a problem, but then it would be hard to keep the strings in the source.

>I do plan to (have somebody else) add  sysctl-variables to the userconfig
>editor.

The ability to configure sysctl variables (not just their values) there
would be overkill :-).

>I anticipate a "bulk" operator for sysctl, either working along the lines
>of readv(2), SNMP's getbulk or by allowing one to fetch entire subtrees at 
>a time, like "kern.vm.*".

Good.

>But I still think we need three types: Int, Text, and Opaque.
>I don't like the concept of converting big structures to ascii and 
>back again, and there are some legitimate uses of entire structures.
>Maybe we should simply adopt the SNMP types without the ASN.1 encoding.

Who mentioned ASCII?  I said scalars.  Everything would be promoted
to a large scalar.  Ints are no use because they may not be big enough
to hold all scalars.  It may be worth optimizing strings.

>I would also love to convert from the int[] names to "char *" at some
>later time.

Why are they `int' anyway?

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511081917.GAA05935>