Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83 based; site houxj.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!houxj!wapd
From: wapd@houxj.UUCP (Bill Dietrich)
Newsgroups: net.arch
Subject: Re: Magic Cookies and File Systems
Message-ID: <478@houxj.UUCP>
Date: Thu, 14-Mar-85 13:12:34 EST
Article-I.D.: houxj.478
Posted: Thu Mar 14 13:12:34 1985
Date-Received: Fri, 15-Mar-85 04:06:51 EST
References: <917@sjuvax.UUCP> <538@rlgvax.UUCP>, <190@u1100s.UUCP> <302@cmu-cs-spice.ARPA>, <171@dmsd.UUCP>
Organization: AT&T Bell Labs, Holmdel NJ
Lines: 30


(Let's keep the discussion friendly and factual, okay ?)


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.

So I think it is easier to know how files are named and to remember
that some files are really locks, some are devices and some are data,
than to remember that there is one way to name locks, another to
name devices, another for data.

I really don't care whether you want to define the naming convention
as names of locks (and some locks happen to have data associated
with them) or as names of files (and some files happen to have locks
associated with them).

As a side comment, at least in Unix, using file names to represent
"pure" locks shouldn't slow down access to regular files.  The kernel
already tests whether a file is regular, character special,
block special, pipe, etc.  "Lock" is just another case.


				Bill Dietrich
				houxj!wapd