Date: Fri, 24 Jul 1998 12:32:04 +0200 (MET DST) From: Willem Jan Withagen <wjw@surf.IAE.nl> To: dfr@nlsystems.com (Doug Rabson) Cc: wjw@IAEhv.nl, hackers@FreeBSD.ORG Subject: Re: SYSCTL ....... Message-ID: <199807241032.MAA19151@surf.IAE.nl> In-Reply-To: <Pine.BSF.4.01.9807241031020.5370-100000@herring.nlsystems.com> from Doug Rabson at "Jul 24, 98 10:40:42 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807241032.MAA19151>