Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Jul 1998 14:39:33 +0200 (MET DST)
From:      Willem Jan  Withagen <wjw@surf.IAE.nl>
To:        witr@rwwa.com (Robert Withrow)
Cc:        wjw@IAEhv.nl, hackers@FreeBSD.ORG
Subject:   Re: SYSCTL .......
Message-ID:  <199807241239.OAA03407@surf.IAE.nl>
In-Reply-To: <199807241217.IAA01417@spooky.rwwa.com> from Robert Withrow at "Jul 24, 98 08:17:29 am"

next in thread | previous in thread | raw e-mail | index | archive | help
You ( Robert Withrow ) write:
=>  Your proposed datatstructures are very space-ineficient, but that
=>  isn't a big deal in a VM environment.  (I come from the position
=>  of writing mib agents for routers, where you don't generally have
=>  VM.)

Well actually it goes into the kernel, and it will be debatable if it is in
VM/hence swappable. Next tot the fact that there are pico-attempts to get
kernels running in small memory.

My major concern goes to "efficiency for lookups". Perhaps that is wrong,
and are there other solutions. Please, educate me.

=>  I think you are making a mistake by providing seperate operations
=>  for "numoids" and "nameoids".  That is because you should also
=>  be able to combine them.  E.G.:
=>  
=>    aaaa.3.5
=>    1.3.6.1.n.n.n.n.n.n.aaaa.3
=>  
=>  I suggest you simply provide an oid parser that "does the right thing".
=>  That is how I do it, and just about everyone else who parses oids does
=>  it.

I would expect that most of the actual parsing is done in userspace.
You point of having a sysctl_find_oid, sounds like a very valid one, with
the minor problem of determining the type of a field. (but that's a very
minor one) It does cut down on writing man-pages. :-)

Then it would also be:
	oid2name and oid2num 
just to get full name oids or full number oids.

=>  Also, if you are going to have a MIB, why isn't it built like "normal"
=>  mibs are built, I.E. with an asn.1 description and a toolchain?  (I'm
=>  asking that of the general FreeBSD crowd.)

I've always wondered wether a MIB could be used to describe, aka generate
C-code and structures, to monitor/control a kernel.
Next of course to the fact that it require a storage model, which was the
actual topic of my previous mail. I wasn't as far as you are.....
(Remember that I started this to make the current sysctl-stuff more dynamic
for other purposes)

=>  Also, why not provide the famous "Awesome Get Bulk" operation?

Is there a need for that in the kernel?
Isn't get_next enough?

--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?199807241239.OAA03407>