Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Jul 1998 01:16:39 +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:  <199807232316.BAA06524@surf.IAE.nl>
In-Reply-To: <Pine.BSF.3.95q.980723201459.349E-100000@herring.nlsystems.com> from Doug Rabson at "Jul 23, 98 08:22:15 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
You ( Doug Rabson ) write:

=>  > Turns out most of it is created by hardcoded structed which are
=>  > joined in what I consider a gruesome hack with linker-sets.
=>  
=>  The linker-set thing is certainly hard to understand but it does work very
=>  well for statically configured data.  The linker does all the work of
=>  building the tree.  As you have noticed, adding data dynamically is a
=>  challenge.

Challenge fall in the "understatement of the week" category.
I've build some compilers before, even using GNU-stuff. But I would not have
thought of doing it this way.
I would certainly win a price in an obfuscated code contest.

=>  > And one of the questions is:
=>  > 
=>  > 	Why did Mike Karels create such a difficult way of doing this?
=>  
=>  I believe that Poul Henning did the linker set thing.  The original 4.4
=>  code was even harder to extend...

Well, cudos to Poul, since he would have had a real bad time.
And it does work, the the lack of dynamic allocation is more or less
killing. Atleast it is for what I want(ed) to do.

=>  I have been avoiding doing this bit of work for literally years ;-).
=>  I will be happy to review any code which you produce.

Meaning:
	You'll review and commit if aproved?

=>  > 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.

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.

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
	
--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?199807232316.BAA06524>