jdb@mordor.UUCP (John Bruner) (03/27/85)
> 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
guy@rlgvax.UUCP (Guy Harris) (04/01/85)
> 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