Date: Fri, 24 Jul 1998 10:40:42 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: wjw@IAEhv.nl Cc: hackers@FreeBSD.ORG Subject: Re: SYSCTL ....... Message-ID: <Pine.BSF.4.01.9807241031020.5370-100000@herring.nlsystems.com> In-Reply-To: <199807232316.BAA06524@surf.IAE.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.01.9807241031020.5370-100000>