Subject: Re: sysctl(2) and/or /kern for system variable manipulation
To: None <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 03/27/2000 03:11:44
[ On Sunday, March 26, 2000 at 22:40:18 (-0500), der Mouse wrote: ]
> Subject: Re: sysctl(2) and/or /kern for system variable manipulation
> > The point of using the filesystem paradigm is to provide a simple and
> > common system-call interface through open(), close(), read(), and
> > write().
> Why is this good?
Your question isn't really meaningful to me in this context. As you no
doubt already know one of the common things people will say about
Unix-like systems is that their most distinguishing feature is the
concept of "everything is a file" (as a quick search for that phrase on
google.com will reveal). Unix doesn't (yet) take this as far as it can
go of course.
The basic advantage is that common tools can be used to manipulate new
services and devices without having to be re-designed with a new
interface tacked on the side of each. Any program can open a tape drive
device and write to it or read from it without knowing that it's
interface is via SCSI, or IDE, or QIC36, or something unique. Obviously
this does mean that to be truly successful anyone employing this
paradigm really must get rid of hacks like ioctl() (either that or make
them generic enough and extensible enough such that they could be used
from the shell command line without having to re-compile the shell every
time a new device driver is added, though how this would fundamentally
differ from simply providing a read/write control channel beats me).
From the Plan-9 FAQ we also read:
What are the advantages to this approach?
Plan 9's approach improves generality and modularity of application design
by encouraging servers that make any kind of information appear to users
and to applications just like collections of ordinary files.
Of course Plan 9 takes "everything is a file" to a new level and really
does eliminate many of the system calls that are unnecessary when you've
got names in the filesystem that can provide the same information and
controls (eg. time(2) is replaced by /dev/time). Small is beautiful and
there's elegance in treating everything uniformly.
Some further explanation is given in "The Design and Implementation of
the 4.4BSD Operating System" book, in particular for /proc, but I would
recommend reading the Plan 9 "early papers" related to this subject as
well as the papers published about some of the earlier implementations
in Research UNIX. Note that the early implementations of /proc were
very primitive in this sense but they've come a long way, especially if
you look at what SysVr4.2 did with it.
I think these two papers are perhaps the best to answer your question
(I've only read the first, not the second):
T. Killian, ``Processes as Files'', USENIX Summer Conf. Proc., Salt
Lake City, 1984
R. Needham, ``Names'', in Distributed systems, S. Mullender, ed.,
Addison Wesley, 1989
Here are some more random references on related topics:
Stevens & Pendry, ``Portals in 4.4BSD'', USENIX Winter Conf. Proc.,
Plan 9 From Bell Labs
Rob Pike, Dave Presotto, Sean Dorward, Bob Flandrena, Ken
Thompson, Howard Trickey, and Phil Winterbottom
An overview of the system; read at least this paper before you
David L. Presotto and Dennis M. Ritchie, ``Interprocess Communication
in the Ninth Edition Unix System'', Softw. - Prac. and Exp., June
1990, Vol 20 #S1, pp. S1/3-S1/17.
The Use of Name Spaces in Plan 9
Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, and Phil
What's in a name?
The Organization of Networks in Plan 9
Dave Presotto and Phil Winterbottom
Connecting the pieces.
S. Childs, ``Filing system interfaces to support distributed
multimedia applications.'', Eighth ACM SIGOPS European Workshop
Support for Composing Distributed Applications, Sintra, Portugal,
After some quick research with google.com I found an interesting paper
that proposes "everything is a box" as an alternative to files:
Seems NTFS goes further too:
In NTFS, everything is a file. Even all metadata are stored in files
called system files. It is quite unusual for a filesystem, but it
allows the filesystem driver to manipulate these data in a generic
way (for example, to perform access control on them), and since these
data can be moved and located anywhere on the storage unit, it
reduces the risk of damage. The Master File Table (MFT) is the most
important system file. It contains information about all the files of
the volume. There is exactly one MFT per volume.
(not that I believe all their claims.... :-)
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>