Path: utzoo!attcan!uunet!ogicse!ucsd!usc!cs.utexas.edu!fletcher
From: ske@pkmab.se (Kristoffer Eriksson)
Newsgroups: comp.std.unix
Subject: Re: Unified I/O namespace: what's the point?
Message-ID: <13390@cs.utexas.edu>
Date: 8 Oct 90 20:56:03 GMT
References: <13220@cs.utexas.edu> <13343@cs.utexas.edu>
Sender: fletcher@cs.utexas.edu
Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden
Lines: 55
Approved: fletcher@cs.utexas.edu (Guest Moderator, Fletcher Mattox)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: ske@pkmab.se (Kristoffer Eriksson)

In article <13220@cs.utexas.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Now we're looking at another possible addition to UNIX that hasn't been
>widely tested: a unified namespace for opening all I/O objects.
>
>I propose that we stop discussing this issue in comp.std.unix and start
>implementing real-world solutions.

I am already running a system where a file name can lead to any kind of
I/O object. It works fine, as far as I can judge. What more should I do?

(Not everything that could be is implemented via file names in this system,
but there are networks and databases that are interfaced via this mechanism,
and I like it a lot. Server programs attach themselves to directory or file
names, and will take care of all file operations attempted by clients on
this file or directory.)

> My approach is to separate opening and connecting into special programs,
>and stick to file descriptors for almost all applications.

Doesn't your objection about the semantics of open() on network connections
fall down in that case? Do your special programs for obtaining the file
descriptors make the real semantics of network connections available to
the application any more than open() does?

I think file names are more useful. How do you for instance stick a file
descriptor that you obtained by one of your special programs into the
configuration file for some program? File names are readily suitable for
that. If you just stick the network address into the file, the application
will be restricted to network connections (maybe only one type of network,
at that), and the application will have to know how to access that kind of
connection.

> If you have a different solution, such as
>overloading open(), why don't you start playing with your library and
>seeing what works? 

Too static. You will in practice be conserving the top level of the name
space inside your library routines. With non-shared libraries this would
mean you'ld have to recompile all your programs if you need to change
what kind of objects you can access or how they are accessed. With chared
libraries this only requires recompiling the libraries, but still isn't
something you'ld like to do every day. With the entire name space available
through the filesystem, you can change the entire hierarchy dynamically,
and starting the server for some kind of objects may as part of that same
operation establish the access path (just a file name) through which it is
accessed.
-- 
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: +46 19-13 03 60  !  e-mail: ske@pkmab.se
Fax:   +46 19-11 51 03  !  or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske


Volume-Number: Volume 21, Number 193