Date: Thu, 04 Jun 1998 13:29:45 -0700 From: Mike Smith <mike@smith.net.au> To: dyson@FreeBSD.ORG Cc: jonny@jonny.eng.br, hackers@FreeBSD.ORG Subject: Re: kernfs/procfs questions... Message-ID: <199806042029.NAA01825@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 04 Jun 1998 02:44:46 CDT." <199806040744.CAA00761@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806042029.NAA01825>