Date: Wed, 03 Jun 1998 22:36:44 -0700 From: Mike Smith <mike@smith.net.au> To: dyson@FreeBSD.ORG Cc: jonny@jonny.eng.br (Joao Carlos Mendes Luis), mike@dingo.cdrom.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: kernfs/procfs questions... Message-ID: <199806040536.WAA00588@antipodes.cdrom.com> In-Reply-To: Your message of "Wed, 03 Jun 1998 23:41:14 CDT." <199806040441.XAA00768@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Joao Carlos Mendes Luis said: > > > > Then, /dev/kmem is bogus ? > > TM > > The idea that file namespace controls everything is a GoodThing, > > and the existence of device files is one of the things I like > > more in Unix. > > > That is reducing things to the absurd. I don't like the silly > string parsing in the debug control for procfs for example. The > bad thing about multiple namespaces is when they aren't well supported, > poorly designed and not hierarchical like the SYSV IPC stuff. > > Think of this issue: > When writing a message to a /kernfs file to modify a function, > do you want to implement a full and general interface for partial > message transfers, etc??? Sysctl is pseudo-message based, and > operations are complete within themselves. 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. > > 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) > If someone wants to use the kernfs paradigm, it is okay, but it > seems to be redundant. Using sysctl is quite trivial (the man page > reflects a much nicer API than the original.) Also, kernfs implies > a filesystem, and the associated VFS stuff, while it isn't needed > with sysctl. You don't need vnodes, or any of the other cruft > to implement the unnecessary state for sysctl, while filesystems > have to implement all kinds of things... The biggest win from the filesystem complexity is traversal that works. I implemented the entire DMI parameter space as a self-handling sysctl hierarchy the other day. It worked fine insofar as you could look things up if you knew they were there, but sysctl makes no provision for traversal through self-handled subtrees, and it would be slightly difficult to add without a major interface change. 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... (No, the DMI code isn't going anywhere fast. You can do everything I did by reading from /dev/mem; I haven't implemented the procedural interface yet because they use the demented 16-bit protected mode PnP interface and Jonathan isn't happy with our support for that yet.) -- \\ 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?199806040536.WAA00588>