From owner-freebsd-hackers Fri Jul 24 02:40:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA29570 for freebsd-hackers-outgoing; Fri, 24 Jul 1998 02:40:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA29484 for ; Fri, 24 Jul 1998 02:40:09 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.8/8.8.5) with SMTP id KAA05511; Fri, 24 Jul 1998 10:40:42 +0100 (BST) Date: Fri, 24 Jul 1998 10:40:42 +0100 (BST) From: Doug Rabson To: wjw@IAEhv.nl cc: hackers@FreeBSD.ORG Subject: Re: SYSCTL ....... In-Reply-To: <199807232316.BAA06524@surf.IAE.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 24 Jul 1998, Willem Jan Withagen wrote: > Meaning: > You'll review and commit if aproved? Yes. > > => > And the most important: > => > Any body with suggestions and/or pitfalls to avoid? > => > => 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. > > The main issue here is that the data-structure is fully dynamical. And > follows the MIB idea: which has identifiers: > N^n or S^n > where N is either a number or S a string. Given a certain prefix: > a.b.c.d > of the sequence a.b.c.d.e then the element N_e and S_e have a fixed > matching relation. (Call each level a layer of hierachy in the nameing > space, or more compiler like: scope) > However if the sequence is: > w.x.y.z.e' > then again N_e' and S_e' are a matching pair. But there is no relation > between S_e and S_e', although N_e and N_e' can have the same value. > this disjunct relation also hold for all other relation which are part of > the OIDnodes e and e'. > > The numeric sequences are more/most important entry for the structure. > This due to the idea have on SNMP-mib's. > > So what I want to implement is a forest of dubble linked binary trees for > each of the layers in the OID space. Each of these hierachies is connected > with parent and child relations to the previous (and following). > The tree themselves hold binary links for the numbers for the OID and > another set for the names. This creates what I would eufemisticly would call > a megaforest of dubble linked binary trees. :-) Note that the trees > themselves will be relatively small, in most cases. I'm afraid that you lost me a couple of paragraphs back. Sounds good though :-) > > Given the fact that one of the most common operators on a MIB-tree will be > get_next, I'm considering adding a UP-relation as well. This will make it > possible to get back to the one-higher node in the same tree. > (Another way of doing it would be recursive descend on the whole > megaforest.) > > 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? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message