Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!fletcher
From: barmar@think.uucp (Barry Margolin)
Newsgroups: comp.std.unix
Subject: Re: Names vs. fds -- it's a floor wax *and* a dessert topping
Message-ID: <13690@cs.utexas.edu>
Date: 17 Oct 90 01:55:19 GMT
References: <13392@cs.utexas.edu> <13441@cs.utexas.edu> <13642@cs.utexas.edu>
Sender: fletcher@cs.utexas.edu
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 65
Approved: fletcher@cs.utexas.edu (Guest Moderator, Fletcher Mattox)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: barmar@think.uucp (Barry Margolin)

In article <13642@cs.utexas.edu> chip@tct.uucp (Chip Salzenberg) writes:
>According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
>>3. A unified namespace has not been tested on a large scale in the
>>real world, and hence is an inappropriate object of standardization
>>at this time.
>"Advancement by invented standards" is an oxymoron, true.  Given that
>POSIX seems to be intent on inventing *something*, though, I push for
>a unified namespace.  Several people have described work with Unix (or
>Unix-like) systems that keep everything in one namespace.  And surely
>Plan 9 counts as "prior art."

Multics also has a unified namespace, although I suspect its interface
would not be considered acceptable by most Unix folks (when users interface
to it, the result looks a bit JCLish).

Rather than forcing everything into the file system hierarchy, Multics's
generalized I/O system is based on dynamically linking to the procedure
that knows how to open a particular type of I/O device.  The Multics
equivalent to open() takes a character string, called an "attach
description" that looks like a command line.  The first token in the string
is transformed into the name of a subroutine, the dynamic linker is invoked
to load the subroutine, and the remaining arguments are collected into an
array of character strings that are passed as the argument list.  For
instance, to open a file the call would look something like:

	fd = attach ("file /foo/bar/baz");

I've translated from Multics and PL/I style to Unix and C.  The Multics
version also has an additional argument, to specify a label for the file
descriptor, as there are commands to list and manipulate the attachments of
the current process (note that on Multics the entire login session is a
single process).

As another example, to attach to a TCP stream, the rsh command might do:

	fd = attach ("tcp think.com -port shell -privileged_local_port");

On Multics, there's a separate open() that is used after attach() (and,
correspondingly, separate close() and detach()).  Attach() says what device
(physical, as in a tape drive, or virtual, as in a file) you're attaching
to, while open specifies how you're using it at any particular time (input
vs output, file name on a labeled tape, etc.).  In the case of devices such
as tape drives, this distinction allows keeping a tape drive reserved to
the process while opening and closing individual files.

The user interface to this is the "io" command, with syntax like:

	io attach stdin file /foo/bar/baz
	io open stdin -input

To fit this into Unix, you'd have to make a variant of > and < that is
follwed by an attach description rather than a filename.  Actually, you
could just use pipes, e.g.

	io attach stdout tape -drive 0 | dd ... | io attach stdin tcp ...
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar


Volume-Number: Volume 21, Number 206