Date: Wed, 08 Nov 1995 09:30:27 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c Message-ID: <1072.815819427@critter.tfs.com> In-Reply-To: Your message of "Wed, 08 Nov 1995 04:41:50 %2B1100." <199511071741.EAA12200@godzilla.zeta.org.au>
next in thread | previous 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. #ifdef TERRY_MODE The only thing we could possibly do which would be a benefit, would be to make an intelligent FreeBSD preprocessor that ran over all the sources first and did some of all the grunt work we presently overload cpp with. This would for instance allow us to split data into two classes, one of which could be returned to malloc/free when it wasn't used anymore, allow us to make pinned/unpinned sections of drivers so that we could page part of the kernel (!) and so on... #endif /* TERRY_MODE */ 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. I do plan to (have somebody else) add sysctl-variables to the userconfig editor. 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.*". Yes, I would really love to kill the "struct" variables in the sense of everything interesting in them be available as simple variables too. 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. I would also love to convert from the int[] names to "char *" at some later time. For now, I'm only working on step one, replace the current definition- method with something more flexible, comprehensive and usable. Functional enhancements will follow later. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1072.815819427>