From owner-freebsd-hackers Thu Jun 4 09:51:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA13165 for freebsd-hackers-outgoing; Thu, 4 Jun 1998 09:51:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA13135; Thu, 4 Jun 1998 09:50:59 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA24630; Thu, 4 Jun 1998 10:50:53 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA02787; Thu, 4 Jun 1998 10:50:51 -0600 Date: Thu, 4 Jun 1998 10:50:51 -0600 Message-Id: <199806041650.KAA02787@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dyson@FreeBSD.ORG Cc: mike@smith.net.au (Mike Smith), hackers@FreeBSD.ORG Subject: Re: kernfs/procfs questions... In-Reply-To: <199806040744.CAA00761@dyson.iquest.net> References: <199806040536.WAA00588@antipodes.cdrom.com> <199806040744.CAA00761@dyson.iquest.net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Again, reducing to the absurd. Why add yet another non-file like > file??? Because that's the Unix way. :) > If you want to emulate the NT registry with a filesystem, that is > okay with me :-). Instead, we emulate the NT registry directly, w/out the filesystem that people can easily browse. :( > One cool thing about sysctl vs. kernfs type schemes, is that for > the kernfs to be useful for shell scripts, you have to do the > ascii to binary and vice versa conversions (assuming that the kernel > isn't doing brain-dead ascii/binary/ascii conversions.) You have to do that in your shell scripts anyway. You have to know what data types are coming from the system, since everything is read as a string in the first place (and you have to parse out the sysctl stuff, etc...) > sysctl has a usable command interface. It is very easy to use > the sysctl system calls and/or library routines. Who cares if you > can't mmap it? That wouldn't make much sense anyway. For byte-counters, > there is alot more good that you can do with the wasted vnodes that > would be utilized by such a filesystem :-). Byte counters shouldn't be in sysctl. 'sysctl' == System Control, not system monitoring. This isn't (and shouldn't be) an SNMP system, which if you've ever had to use is a nightmare to work with w/out a huge document explaining all of your MIB's, which vary from vendor to vendor. Sysctl is exactly that but worse, since there is *NO* set of MIB (nodes) that are standard, so every FreeBSD user has to become a sysctl expert and memorize the hierarchy in order to fully utilize it. In other words, *MORE* esoteric stuff to remember, making FreeBSD/unix that much harder to administer. Do I have a better solution Jordan asks? The FS interface is *harder* for the kernel developer, but easier for the administrator. Nate's #1 rule of programming complexity: "You can't reduce complexity of a problem below a certain point. You can move it around, but at some point it has to be somewhere." This means that *someone* is going to have to deal with it, and the fact of the matter is that if we want unix to have more users then it should be the developers who have to work a bit harder to do it. (BTW, I have a corollary to the above rule that states "Just because a problem is complex doesn't mean it can't be simplified, or that all of the complexity is necessary." ;) Doing a job poorly or making the users memorize esoteric namespaces just for the sake of 'checking off a feature box' is not doing the user-base any favors. Anyone motivated enough to figure it out how to configure a specific machine may like you, but the general user population will never benefit from that work since they don't have the time or ability to figure it out. In other words, you'll end up working really hard for 1-2 sites, and no one else will aprreciate/use the resulting hard-work put in. For a volunteer project, this is a shame. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message