From owner-cvs-sys Wed Nov 8 11:22:08 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA15397 for cvs-sys-outgoing; Wed, 8 Nov 1995 11:22:08 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA15392 ; Wed, 8 Nov 1995 11:22:00 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA05935; Thu, 9 Nov 1995 06:17:51 +1100 Date: Thu, 9 Nov 1995 06:17:51 +1100 From: Bruce Evans Message-Id: <199511081917.GAA05935@godzilla.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 Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk >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