Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.internals Subject: Re: Ideas for changes to Unix filesystem Message-ID: <5934@auspex.auspex.com> Date: 11 Feb 91 22:00:26 GMT References: <1991Feb7.064348.1873@sgitokyo.nsg.sgi.com> Organization: Auspex Systems, Santa Clara Lines: 47 In article <1991Feb7.064348.1873@sgitokyo.nsg.sgi.com> kandall@sgitokyo.nsg.sgi.com (Michael Kandall) writes: >In article igb@fulcrum.bt.co.uk (Ian G Batten) writes: >>In article bzs@world.std.com (Barry Shein) writes: >>> Think of fixed length record files and inserting into them, it would >>> be nice to be able to just copy/munge the block numbers rather than >>> the data. >> >>What's needed is a version of streams for filesystems. With Multics, >>the One True Operating System, you could attach modules (== push >>modules) such as vfile_ to provide additional functionality over and >>above that which you got from initiate_segment_ and its friends. What >>would be nice with Unix would be ISAM, record mode, whatever modules you >>could push on top of the mmap interface. Once you can map files into >>your address space most things can be done on top of that. >> >>ian > >I believe SVR4 has this. In SVR4's enhanced STREAMS, I believe you can >push STREAMS onto arbitrary file descriptors. You believe incorrectly. What S5R4 *does* have is the ability to attach a STREAMS-device file descriptor to a "node in the file system name space", using "fattach()". This does *NOT* magically turn a regular file into a STREAMS device; it turns it into a name for a STREAMS device. I.e., anybody who opens the file after you've "fattach()"ed something to it will *NOT* get a file descriptor that reads from or writes to the underlying file; the underlying file merely provides a *name* for the stream. What Ian was describing sounds more like the stuff Apollo did - with the name "Extensible Streams", but where "Streams" has nothing to do with "streams" in the Research UNIX sense or "STREAMS" in the S5 sense. The low-level means of accessing a file is by mapping into a process's address space; atop that is built a mechanism for more "conventional" file access, with each file having an "object type UID". The "object type UID" indicates what code acts as a "type manager" for the file; that "type manager" code implements operations such as "open", "read", "write", etc.. Dunno if they were "stackable" like (streams|STREAMS) modules. (Then again, I don't remember whether modules were stackable in any of Multics's I/O subsystems, either "ios_" or "iox_".) I think the type managers all lived in user-mode code. That doesn't necessarily give you the stuff Barry was referring to; the "containers" provided by the (probably kernel-level) file system are arrays of pages, similar to UNIX files. Unless there was an interface to that file system that let you insert pages into the middle of a container, you wouldn't be able to do an insert like that. Brought to you by Super Global Mega Corp .com