From owner-freebsd-hackers Fri Jul 24 03:32:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA09311 for freebsd-hackers-outgoing; Fri, 24 Jul 1998 03:32:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA09303 for ; Fri, 24 Jul 1998 03:32:28 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id MAA25177; Fri, 24 Jul 1998 12:32:05 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id MAA19151; Fri, 24 Jul 1998 12:32:05 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807241032.MAA19151@surf.IAE.nl> Subject: Re: SYSCTL ....... In-Reply-To: from Doug Rabson at "Jul 24, 98 10:40:42 am" To: dfr@nlsystems.com (Doug Rabson) Date: Fri, 24 Jul 1998 12:32:04 +0200 (MET DST) Cc: wjw@IAEhv.nl, hackers@FreeBSD.ORG Reply-To: wjw@IAEhv.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You ( Doug Rabson ) write: => > => Last time I was daydreaming about sysctl, I thought that using SYSINIT => > => functions to build the tree would be a good idea. This would have the => > => benefit of trivially adding in sysctl variables in kernel modules loaded => > => using KLD since it runs SYSINITs in the loaded modules. To support => > => unloading modules, a method of automatically disconnecting variables => > => defined by the module is needed. => > => > Intresting point. => > I haven't thought about this point. I considered that once submitted OID's => > are there for ever. But evaporating LKM's would case some access trouble. => => I think that coping well with loading/unloading modules is a requirement => since supporting loadable drivers (and other components) is a goal we => should be working towards. It could have some influence on the data-structures if deleteing nodes is a frequent operation. The alternative would be to invalidate te content pointers. It also puts a serious commitment by the LKM-builder. He needs to make shure he unregisters everything he has registered. Which could be more than he/she bargained for. => I'm afraid that you lost me a couple of paragraphs back. Sounds good => though :-) I've rewritten it twice, because the other descriptions were even more illedigble. Perhaps the code will be more understandable. => > The major element will be a routine to insert nodes into this tree: => > by number and name, creating nodes on the "fly" if needed. => > by number only, giving no names to values in each scope. => > by name, possibly giving "random" numbers to the names on each scope => > => > Other routines will be: => > sysctl_-find_by_numoid => > .. find_by_nameoid => > .. name2num => > .. num2name => > .. findnext_by_numoid => > .. get_by_numoid => > .. modify_by_numoid => => And of course, the existing macros for defining simple sysctl variables => will be supported? I'm intending to build a glue layer for the old stuff. There is going to be one tinny problem: Since creation is currently done link/compile time, these creation actions are currently macros which are not included in any executed environment. So something is going to break .... Which I tend to fix by going over all SYSCTL_ stuff in the kernel and replace which the new functions. It is relatively straightforward, but a lot of grunt work. Unless I really have a ball, and copy whatever is in the static structure to the dynamic structure. Thus waisting some allocated space, which is not much at the moment. Trouble is, that if I do it this way, old_sysctl is going to be there for a long long time. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message