From owner-freebsd-hackers Thu Jun 4 00:45:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA19501 for freebsd-hackers-outgoing; Thu, 4 Jun 1998 00:45:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA19464; Thu, 4 Jun 1998 00:44:58 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id CAA00761; Thu, 4 Jun 1998 02:44:46 -0500 (EST) (envelope-from toor) Message-Id: <199806040744.CAA00761@dyson.iquest.net> Subject: Re: kernfs/procfs questions... In-Reply-To: <199806040536.WAA00588@antipodes.cdrom.com> from Mike Smith at "Jun 3, 98 10:36:44 pm" To: mike@smith.net.au (Mike Smith) Date: Thu, 4 Jun 1998 02:44:46 -0500 (EST) Cc: dyson@FreeBSD.ORG, jonny@jonny.eng.br, mike@dingo.cdrom.com, mike@smith.net.au, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (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 Mike Smith said: > > The write has to be a single, complete operation. That more or less > goes without saying. The issue is whether you are willing to have > these implicit controls on something that you might think "should" > behave entirely like a file. This still kills a lot of /dev, but it's > also generally assumed that things mounted from "special" filesystems > may have "special" semantics. > Preface this with: Conversions in the kernel are ugly. They should be done by a user space program. Sysctl provides a consistant interface from kernel binary formats to user friendly formats, without conversions in kernel space... Again, reducing to the absurd. Why add yet another non-file like file??? Hmmm??? Are we justifying wierd semantics by other cases of wierd semantics? Sometimes the wierd semantics might make sense, but you can do most if not all of what makes sense with simple shell scripting and the sysctl command. The sysctl system call/subroutine(s) are very simple to use, for their purposes. If you want to emulate the NT registry with a filesystem, that is okay with me :-). It seems to me that there is a case for a limited kernfs, but why use such a heavyweight scheme, when sysctl works just fine for most purposes? Pieces that might be useful to be dynamic, then the filesystem might be okay, but it seems to be a tool looking for a purpose. 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.) With sysctl, the types are managed for you in user space. :-). I think that it is extremely ugly to have to ascii convert things in the kernel (even though I am guilty of it.) By the time you create a filter to do the conversions (using a more reasonable kernel binary interface), then you have yet another sysctl program to interpret your kernfs. :-). Again, a kernfs for most of the purposes that we use sysctl for is just too heavyweight in the kernel. > > > > I agree with somebody (Mike ?) who said that this facilitates > > > using of general tools. > > > > > Sysctl is easy to use with such tools also. > > The current interface to sysctl sucks. I certainly can't use cat(1) on > it. I can't open it and parse it with sscanf(). I can't mmap() it > either, and it would be very nice to be able to do that. 8) > 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 :-). > > If you go look like a filesystem, this happens automatically. It is > also one of the things that would prevent a sysctlfs being trivially > implementable. Imagine a node that looked like a file, but was > actually a directory... > The filesystem paradigm for sysctl things is simple overkill and typical of the "you can do everything with a hammer" mentality. This degrades into the mmaping of tty's type discussion. I suggest that if you would like a feature, then implement it. BTW, if someone wants to do some filesystem hacking, our procfs only needs a little cleanup to almost fully support PS without the proc size mismatch problem. There are some things that might make sense in a kernfs, but most of the kernel state setting and retrieval functions do not make sense in kernfs. Type conversion to printable formats belongs in userspace (within reason.) -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message