Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site lanl.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!panda!talcott!harvard!seismo!cmcl2!lanl!jlg
From: jlg@lanl.ARPA
Newsgroups: net.arch
Subject: Re: Magic Cookies and File Systems
Message-ID: <23434@lanl.ARPA>
Date: Mon, 18-Mar-85 15:36:47 EST
Article-I.D.: lanl.23434
Posted: Mon Mar 18 15:36:47 1985
Date-Received: Fri, 22-Mar-85 23:43:26 EST
References: <917@sjuvax.UUCP> <538@rlgvax.UUCP>, <190@u1100s.UUCP> <302@cmu-cs-spice.ARPA>, <171@dmsd.UUCP> <478@houxj.UUCP>
Sender: newsreader@lanl.ARPA
Organization: Los Alamos National Laboratory
Lines: 24

> I agree with the side that says locks or resources or whatever
> should look like files if possible.  The reason is that the
> user should have to deal with as few naming conventions or
> ideas as possible.  If everything can be unified into one
> naming convention (tree-structured, path-names), the user will
> have a managable number (one) of things that must be understood
> on the way to solving the problem that is of interest.

I agree with the above philosophy but not with the terminology.  There
should indeed be only one system pool for name/resource management.  But
this is NOT the file system.  The main function of the file system is to
provide a mechanism for data transfer between a process and certain types
of resources.  Locks and semaphors (as well as perhaps other resources)
don't need this functionality of the file system and should not be
associated with the file system.

Note that the file system will use whatever resource naming convention is
implemented by the appropriate part of the OS.  The file system may also
use locks or semaphors which are implemented within the OS (to prevent two
processes from simultaneously writing to the same place, for example).
Both of these things are functions of the operating system which are
distinct from the file system.

J. Giles