Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site mordor.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!ut-sally!mordor!jdb
From: jdb@mordor.UUCP (John Bruner)
Newsgroups: net.arch,net.micro.16k,net.micro.68k
Subject: segmentation vs. file I/O
Message-ID: <1280@mordor.UUCP>
Date: Wed, 27-Mar-85 14:56:43 EST
Article-I.D.: mordor.1280
Posted: Wed Mar 27 14:56:43 1985
Date-Received: Mon, 1-Apr-85 13:28:24 EST
References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP>
Organization: S-1 Project, LLNL
Lines: 43
Xref: watmath net.arch:1049 net.micro.16k:304 net.micro.68k:695

> The UNIX (a very chauvinistic) community would do
> well to look at MULTICS (or 4.xBSD and vread
> vwrite) and to contemplate why files exist. Why are they there?
> They are an unpleasant fix to the lack of an unconstrained segmented address
> space. Read and Write are a hack around the `obvious' solution of
> attaching to a named address space and assigning to or accessing the
> value of the notional structures that it contains; be they bytes or
> records. Why use lseek(2) when you could have pointers?

I agree that the UNIX community tends to be a chauvinistic at times;
however, this tendency is not exclusive to UNIX people.  Similar biases
are evident among MULTICS lovers, TOPS-20 lovers, etc.

Although segments are clearly superior to files for some things,
files have their uses as well.

Mapping a named segment into the address space, and manipulating it
directly, is tremendously useful for some classes of problems.  However,
as someone has pointed out, conceptually one wants the segment size
to be resolved on (at most) a byte boundary, and available hardware has
a resolution considerably coarser than this.  One can associate a bit
count with the segment and require the program to update the bit
count (which can be a hassle) or try the "adjust bit count" approach
(and hope that the segment doesn't end with zeros).

The abstraction of a file is also very useful when the input/output
object is a physical device (e.g. a terminal connected via a serial
line).  While lseek() is a little harder to defend, the generality
of "read" and "write" primitives provides a uniform method of access
to different objects.  This generality makes I/O redirection in UNIX
so easy.  By contrast, if a program opens a segment directly and
writes into it, I can't make the output of that program appear on
my terminal or (perhaps) use it as input to another program.

Of course, for random-access objects (or pipes, if the OS supports
multitasking within the same address space), read/write can be
implemented using segments.  This permits a program to view its
external objects as segments (when this is clearly desirable) or as
files (because the model of a file can be applied to more objects).
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb@mordor.ARPA [jdb@s1-c]	(415) 422-0758
  UUCP: ...!ucbvax!dual!mordor!jdb 	...!decvax!decwrl!mordor!jdb