[ 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.,
   January 1995

   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       
           install.                                                             
   http://plan9.bell-labs.com/plan9/doc/9.html

   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      
           Winterbottom                                                         
           What's in a name?                                                    
   http://plan9.bell-labs.com/plan9/doc/names.html

   The Organization of Networks in Plan 9                                       
           Dave Presotto and Phil Winterbottom                                  
           Connecting the pieces.                                               
   http://plan9.bell-labs.com/plan9/doc/net.html

   S. Childs, ``Filing system interfaces to support distributed
   multimedia applications.'', Eighth ACM SIGOPS European Workshop
   Support for Composing Distributed Applications, Sintra, Portugal,
   1998. ACM.

After some quick research with google.com I found an interesting paper
that proposes "everything is a box" as an alternative to files:

	http://gsyc.escet.urjc.es/off/export/2kblocks/2kblocks.html

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.
    
(from http://www.via.ecp.fr/~regis/ntfs/new/MFT.html)

(not that I believe all their claims.... :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>