From owner-cvs-all Mon Jan 11 11:30:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA16539 for cvs-all-outgoing; Mon, 11 Jan 1999 11:30:53 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA16523 for ; Mon, 11 Jan 1999 11:30:47 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id UAA26407; Mon, 11 Jan 1999 20:16:50 +0100 (CET) To: Garrett Wollman cc: Nate Williams , committers@FreeBSD.ORG Subject: Re: Another approach... Re: sysctl descriptions In-reply-to: Your message of "Mon, 11 Jan 1999 07:44:28 EST." <199901111244.HAA13985@khavrinen.lcs.mit.edu> Date: Mon, 11 Jan 1999 20:16:49 +0100 Message-ID: <26405.916082209@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk In message <199901111244.HAA13985@khavrinen.lcs.mit.edu>, Garrett Wollman writes: >< said: > >> sysctl is too general to be documented. It would be like reading the >> perl manpages in hopes of tring to figure out what trim() does. Yes, >> you can find it, but it's not optimal for the many reasons already >> outlined (maintainability, ease of use, etc...) > >I don't believe this to be the case. I've been thinking about what >the right way to handle this might be since the latest flare-up. What >follows is a significant departure from the opinion I've had on this >subject in the past... > >I think, if we want to be serious about describing what's in sysctl(3) >as a ``MIB'', we should sit down and write an ACTUAL MIB, i.e., a hunk >of ASN.1 that is a *specification* for the information we wish to >present. It was my original intention to (ab)use sysctl to implement the relevant bits of MIB-II such that a snmpd deamon would have a minimal amount of work to do. At the time it stalled on several things, one of which were that it would indeed increase the size of our kernel significantly to add that number of variables, and I seriously didn't expect the user community to be sufficiently hooked on SNMP to appreciate the neatness of my approach. As time has gone by, I'm not longer sure about the neatness either. Right now uses of sysctl comes in the following general classes: 1. tweak handles for the kernel like "net.inet.tcp.rfc1644" 2. syscall/libfunc implementation like ntpgettime() and getcwd() 3. state monitoring like struct proc for ps 4. statistics like debug.freevnodes As such I'm not dissatisfied with our current sysctl (mkII), it does most of what we ask from it. (btw: We do have instances, but the sysctl program doesn't know about them, check the "struct proc" stuff) I'm not really sure I agree with Garrett about writing ASN.1 for this stuff. For a FREEBSD-MIB: yes, but not for the kernel interface. (BTW: our IANA registrered enterprise# is 2238) I did have a sysctl mkIII working at one time, which operated out of an opaque binary file, using a "vipw" like editing interface, and it implemented persistence in sysctl, per system/user/session/process search order and God knows what, and about the only thing I could find to use it for was the TZ environment variable! Well, I'm kidding, variant symlinks too, but the legitimate uses of it were not as numerous as I had anticipated at least, and I therefore gave up on it. If we want to go down this route a "registry" is the term we're talking about, and we should seriously design it. NT made some bad mistakes we can learn a lot from. What use would a registry be to us ? Well, primarily a persistent memory for the kernel (editable by the user). The scsi system could store the max number of openings to use for a specific disk instead of having to learn the hardway on each boot (but would it make sense ?) We could store default settings for tty devices (but would it make sense ?) We could store IPFW rules (but does it make sense ?) and so on... Every time I have revisited this, I have concluded that it isn't really "the UNIX way", it's "the Windows way". UNIX boots and come up, and you configure it from there on each reboot. If anything is a POLA not to be transgressed on, it is the ability of a power-cycle and boot into single user mode to be repeatable. The UNIX way, in other words is to not let the kernel know what we're doing, until we tell it, on every boot. That leaves in essence variant symlinks (as known from Apollo/Domain) for instance: ln -s '/usr/${arch}/bin' /usr/bin and other such stuff. Getting the kernel to yank the "${arch}" from the users environment would not be easy, if even the right thing to do, so probably a special name-space for these variables might be needed. Summary: It's not clear to me if we currently have justification for a real registry, on the other hand sysctl seems to be doing pretty well. Streamlining the interface to sysctl could make it a breeze for devices to use it as well. Comments most welcome. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message