From owner-freebsd-hackers Thu Jun 4 14:35:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14108 for freebsd-hackers-outgoing; Thu, 4 Jun 1998 14:35:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14019; Thu, 4 Jun 1998 14:34:32 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id NAA01825; Thu, 4 Jun 1998 13:29:45 -0700 (PDT) Message-Id: <199806042029.NAA01825@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: dyson@FreeBSD.ORG cc: jonny@jonny.eng.br, hackers@FreeBSD.ORG Subject: Re: kernfs/procfs questions... In-reply-to: Your message of "Thu, 04 Jun 1998 02:44:46 CDT." <199806040744.CAA00761@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jun 1998 13:29:45 -0700 From: Mike Smith 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... It even provides format information, yup. And I take your point about conversion overheads. > 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. One of the major drawbacks with sysctl is its handling of large data objects; any objection you can raise against ioctl() can be raised against sysctl as well. > > 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 :-). I can see quite a lot of use in mmapping data; reducing the copy in/out overheads for statistics gathering just for starters. > 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.) Hmm. Thanks for the input. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message