Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site cmu-cs-spice.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!mit-eddie!godot!harvard!seismo!rochester!cmu-cs-pt!cmu-cs-spice!avie
From: avie@cmu-cs-spice.ARPA (Avadis Tevanian)
Newsgroups: net.arch
Subject: Re: Magic Cookies and File Systems
Message-ID: <302@cmu-cs-spice.ARPA>
Date: Sat, 9-Mar-85 04:23:53 EST
Article-I.D.: cmu-cs-s.302
Posted: Sat Mar  9 04:23:53 1985
Date-Received: Mon, 11-Mar-85 07:04:35 EST
References: <917@sjuvax.UUCP> <538@rlgvax.UUCP>, <190@u1100s.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 30

> worse yet, numbers!!) for the names of entities.  The file system directory
> structure is the ONLY logical place for global names of ANY kind to reside.

Would you care to say *why* the file system is the only logical place for
global names to reside?  When I read articles like this, I begin to worry.
As far as I'm concerned, a file is just one of many resources in a system.
In fact, THERE IS NO REASON that the kernel need know what a file is!  Of
course, many of the readers of this newsgroup (hopefully not all) are still
living in the primitive world of "the Unix Way."

We are currently developing a new kernel based on Accent (which was
developed here at CMU).  Our kernel, conceptually, only knows how to
manipulate address maps of processes.  The file system is implemented by
user level processes, which understand the disk format of the file systems,
whether they be on a Fujitsu Eagle, RX01 floppy, or over the ethernet.  When
raw disk I/O needs to be performed, drivers are called.  Even these drivers
need not exist in the kernel proper, except that it is more efficient to put
them in the kernel.

So, in my opinion, it is better to have a general name server, which can
assign names to a variety of objects (files, semaphores, ports, whatever).

Related to locking, it seems to me that doing locking in the file system is
not such a great idea if you want any type of speed.  I wrote up a 4.2
semaphore package (in the kernel) which runs on a VAX 784 (4 780 processors
connected with shared memory).  A P/V combination takes only about 500
microseconds (that includes 2 traps, verification of valid parameters, and
all that ugly stuff).  I'd like to see you do that with file system locking.

	Avie Tevanian