From owner-cvs-sys Wed Nov 8 11:29:58 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA15741 for cvs-sys-outgoing; Wed, 8 Nov 1995 11:29:58 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA15729 ; Wed, 8 Nov 1995 11:29:48 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tDGBv-0003wTC; Wed, 8 Nov 95 11:29 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id UAA03419; Wed, 8 Nov 1995 20:29:48 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: Bruce Evans cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c In-reply-to: Your message of "Thu, 09 Nov 1995 06:17:51 +1100." <199511081917.GAA05935@godzilla.zeta.org.au> Date: Wed, 08 Nov 1995 20:29:44 +0100 Message-ID: <3417.815858984@critter.tfs.com> From: Poul-Henning Kamp 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. Well, how would you dynamically add something to a switch() {} ? I may have forgotten that in my last email but dynamic mgt of sysctl vars is certainly in the plans. I will have to malloc storage for a replacement linker-set of course... too bad I can't free the old one. > Current processing consists of sorting the vectors and probably only > works once (later, there may be pointers into the vectors...). I no. > 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. no, wastes too much storage. Been down that road once. You end up having to store the entire name in each entry. Bad for your RAM. > 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. But not for long. Watch this space :-) > >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 :-). No, actually not. sysctl variables may start to do a lot more work than they do now pretty soon. We used to say that you need to be able to crawl before you can walk, I'm doing that now... -- 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.