From owner-freebsd-hackers Fri Jul 24 05:40:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA29092 for freebsd-hackers-outgoing; Fri, 24 Jul 1998 05:40:20 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA29077 for ; Fri, 24 Jul 1998 05:40:14 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id OAA01081; Fri, 24 Jul 1998 14:39:40 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id OAA03407; Fri, 24 Jul 1998 14:39:34 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807241239.OAA03407@surf.IAE.nl> Subject: Re: SYSCTL ....... In-Reply-To: <199807241217.IAA01417@spooky.rwwa.com> from Robert Withrow at "Jul 24, 98 08:17:29 am" To: witr@rwwa.com (Robert Withrow) Date: Fri, 24 Jul 1998 14:39:33 +0200 (MET DST) Cc: wjw@IAEhv.nl, hackers@FreeBSD.ORG Reply-To: wjw@IAEhv.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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