Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!trwatf!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.arch,net.micro.16k,net.micro.68k
Subject: Re: segmentation vs. file I/O
Message-ID: <599@rlgvax.UUCP>
Date: Mon, 1-Apr-85 01:08:48 EST
Article-I.D.: rlgvax.599
Posted: Mon Apr  1 01:08:48 1985
Date-Received: Thu, 4-Apr-85 15:50:36 EST
References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 18
Xref: watmath net.arch:1067 net.micro.16k:308 net.micro.68k:700

> 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).

This problem also applies to conventional files on systems where the file
abstraction provided by the kernel is of an array of blocks, rather than an
array of bytes, e.g. in RSX-11 and VMS.  FCS and RMS have to maintain a byte
count and update it with a "set file attributes" QIO or somesuch.  It's not
just unique to segments, although it may be felt to be more of an intrusion
on systems with mapped file systems.

	Guy Harris
	sun!guy