std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/02/86)
From: rgenter@labs-b.bbn.com (Rick Genter)
Date: 30 Oct 86 09:57:13 EST (Thu)
Here's the text of my original article, modified to reflect dmr's comments:
The recent discussion regarding the issue of case insensitivity in the
POSIX environment has caused me to think about the Unix file system and
its impact on the kernel. I came into the Unix game late, but as I understand
it, various flavors of Unix (such as MERT, Unix' real-time cousin),
implemented the file system completely outside the kernel, I suppose as a
library of routines. I also understand that the MACH project at CMU is
heading in this direction.
The primary reason that I see for having the file system in the kernel in
the first place is perhaps for efficiency and to solve certain concurrency
problems. I see making the file system case insensitive as another step in
this direction; unfortunately I see it as a step backwards. I suppose the
next logical step would be to put wildcard expansion in the kernel.
If any sort of fundamental change is to be made to the file system for
POSIX, I'd prefer moving towards a non-kernel file system. In addition to
simplifying the design of the operating system, it also allows users to
implement layers on top of the file system, such as case insensitivity,
wildcard expansion, network file systems, access methods, etc. Gee, is this
starting to sound like streams?
Personally, I'd rather that POSIX not change the appearance of the Unix
file system; it's too big a task to do right involving a redesign rather
than a standardization. This is clearly (at least to me) outside the scope
of an effort such as P1003.
--------
Rick Genter BBN Laboratories Inc.
(617) 497-3848 10 Moulton St. 6/512
rgenter@labs-b.bbn.COM (Internet new) Cambridge, MA 02238
rgenter@bbn-labs-b.ARPA (Internet old) seismo!bbncca!rgenter (UUCP)
Volume-Number: Volume 8, Number 13std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/03/86)
From: guy@sun.com (Guy Harris) Date: Mon, 3 Nov 86 00:50:03 PST > I came into the Unix game late, but as I understand it, various flavors > of Unix (such as MERT, Unix' real-time cousin), implemented the file system > completely outside the kernel, I suppose as a library of routines. Yes, and no. They did implement it outside the kernel, although not in user mode. The file system was implemented by a process that ran in supervisor mode and which received messages telling it to do things like read from or write to a file. Other operating systems, like RSX-11 and VMS, did the same thing. I believe the latest descendents of MERT, and VMS, have moved the file system back into the kernel for performance reasons. > If any sort of fundamental change is to be made to the file system for > POSIX, I'd prefer moving towards a non-kernel file system. In addition to > simplifying the design of the operating system, it also allows users to > implement layers on top of the file system, such as case insensitivity, > wildcard expansion, network file systems, access methods, etc. Gee, is this > starting to sound like streams? POSIX does not specify whether the file system is implemented in the kernel or not. Even if a particular POSIX implementation has the file system in the kernel, it can implement things like "case insensitivity, wildcard expansion, network file systems, access methods", etc. on top of the file system. One system that is nearly POSIX-compatible, called the UNIX system, has done the last three of these (wildcard expansion in the shell - this could also be made into a user-mode library; network file systems, such as the Newcastle Connection and IBIS, implemented as user-mode wrappers around calls like "open", "read", "write", etc.; access methods such as C-ISAM, that are just user-mode libraries). Remember, POSIX is an *interface* specification, not an implementation. The fact that many (most?) POSIX implementations, including the UNIX implementation, will have the file system in the kernel says nothing about POSIX. Volume-Number: Volume 8, Number 21
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/04/86)
From: jbs@eddie.mit.edu (Jeff Siegal) Date: Mon, 3 Nov 86 17:44:44 EST Organization: MIT, EE/CS Computer Facilities, Cambridge, MA In article <6206@ut-sally.UUCP> guy@sub.com (Guy Harris) >[...] The file system was implemented by a process that ran in supervisor >mode and which received messages telling it to do things like read from or >write to a file. Other operating systems, like RSX-11 and VMS, did the same >thing. I believe the latest descendents of MERT, and VMS, have moved the >file system back into the kernel for performance reasons. Quite far off, actually (at least in the case of VMS). Current versions of VMS have replaced the disk filesystem ACP (which previously was a separate process) with the XQP, a separate instance of which exists in _each_process_ (the code is shared). This resulted in some significant performance _improvements_, and a filesystem which extends fairly easily and quite completely (including record/file locking, etc.) over different machines (using DEC's inter-system CI bus). Jeff Siegal Volume-Number: Volume 8, Number 31
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/04/86)
From: garry@tcgould.tn.cornell.edu (Garry Wiegand) Date: Tue, 4 Nov 86 00:45:47 EST Organization: Cornell Engineering && Flying Moose Graphics In a recent article jbs@eddie.mit.edu (Jeff Siegal) wrote: >In article <6206@ut-sally.UUCP> guy@sub.com (Guy Harris) >>[...] I believe the latest descendents of MERT, and VMS, have moved the >>file system back into the kernel for performance reasons. > >Quite far off, actually (at least in the case of VMS). Current >versions of VMS have replaced the disk filesystem ACP (which >previously was a separate process) with the XQP, a separate instance >of which exists in _each_process_ (the code is shared). [...] Sorry to quibble, but the original posting was accurate. There is now a piece of the kernel which Dec has labelled the "XQP". The code runs in the context of a user-process, as is indistinguishably true of every other system service. The stated reason for making the move was increased performance. That the cluster software was easier to write was probably a bonus. garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu) Volume-Number: Volume 8, Number 32
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/05/86)
From: seismo!hadron!jsdy@sally.utexas.edu (Joseph S. D. Yao) Date: Tue, 4 Nov 86 23:03:27 est Organization: Hadron, Inc., Fairfax, VA In article <6193@ut-sally.UUCP>: >From: rgenter@labs-b.bbn.com (Rick Genter) >Date: 30 Oct 86 09:57:13 EST (Thu) > >... various flavors of Unix (such as MERT, Unix' real-time cousin), >implemented the file system completely outside the kernel, I suppose as a >library of routines. ... > If any sort of fundamental change is to be made to the file system for >POSIX, I'd prefer moving towards a non-kernel file system. In addition to >simplifying the design of the operating system, it also allows users to >implement layers on top of the file system, such as case insensitivity, >wildcard expansion, network file systems, access methods, etc. Gee, is this >starting to sound like streams? The details of implementation, such as in or out of the kernel, and streams, are really irrelevant. Having the file system as a separate, layerable part of the system interface as a whole is a wonderful idea. This conforms with ideas of modularity, motherhood, apple pie, and so forth. Both 4bsd and s5 have, in succeeding implementations, tried to isolate FS code at least by file in the os:sys directories. Recent versions of the Unix(R) operating systems even implement file system switches, which are the next great step, and would probably do everything that Rick or anyone else would like, even to mounting MS-DOS, VMS, TOPS-20, or whatever file systems. (Yes, even 4.2+ FS's on traditional Unix FS's!) But I haven't seen much about them since they were first ballyhooed; and AT&T even seems to be withdrawing theirs. (They won't document it, saying that they don't want anyone to use it because it might go away.) Perhaps this just means that they're thinking of adopting the Sun version as a "standard"? Does anyone know anything about this? -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised) Volume-Number: Volume 8, Number 39