home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 January
/
usenetsourcesnewsgroupsinfomagicjanuary1994.iso
/
sources
/
std_unix
/
v21
/
133
< prev
next >
Wrap
Internet Message Format
|
1990-12-05
|
2KB
From std-unix-request@uunet.uu.net Wed Sep 26 17:30:40 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
id AA19979; Wed, 26 Sep 90 17:30:40 -0400
Posted-Date: 26 Sep 90 12:19:06 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: ske@pkmab.se (Kristoffer Eriksson)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <545@usenix.ORG>
References: <523@usenix.ORG> <539@usenix.ORG> <541@usenix.ORG>
Sender: jsq@usenix.ORG
Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden
X-Submissions: std-unix@uunet.uu.net
Date: 26 Sep 90 12:19:06 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Submitted-by: ske@pkmab.se (Kristoffer Eriksson)
In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In the filesystem abstraction, you open a filename in one stage. [...]
>
>You can easily construct other examples, but one should be enough to
>convince you that open() just isn't sufficiently general for everything
>that you might read() or write().
What prevents us from inventing a few additional filesystem operations
that ARE general enough?
I think the important thing about the filesystem abstraction that is being
debated here, is the idea of a common name space, and that idea does not
require open() to be an indivicible operation, and it does not require that
open() must be the only way to associate a file descriptor to a named object,
as long as there is only one name space.
--
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 133