Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.os.misc Subject: Re: What constitutes a good OS? Message-ID: <5509@auspex.auspex.com> Date: 24 Jan 91 23:31:19 GMT References: <42488@nigel.ee.udel.edu> <5461@auspex.auspex.com> <11469@darkstar.ucsc.edu> Organization: Auspex Systems, Santa Clara Lines: 108 >In general, this whole argument seems silly. Nobody in their right >mind is going to provide *any* kind of file system in the kernel, if >current trends are to be believed. Any operating system worth >consideration would be able to use a new "filesystem" module (object, >server, ...) which provided complex semantics. And Unix functionality >does seem to be the basis people are using to develop new systems. I think much of the problem here is that people are getting hung up by the fact that there are two levels at which UNIX - and some other systems - provide "file system" functionality. The levels are the "container" level and the "structure" level. The level that is typically implemented by the kernel on UNIX systems is a "container". UNIX files, at that level, are randomly-accessible arrays of bytes, with no structure. The structure is - with the exception of directories - provided by stuff running atop that level, usually in user mode. Examples: The standard I/O library knows, in some places, about "text files", which consist of sequences of bytes with newline characters ending "lines" - and, at least for "(f)gets()" and "(f)puts", containing no '\0' characters. Some utilities that don't use standard I/O, or that use interfaces such as "getc()" and "putc()", know about "text files" as well. The "(n)dbm" library knows about keyed files, as do various ISAM libraries supplied by the vendor or by third parties. Assemblers and linkers, various libraries and library routines, run-time linkers in e.g. SunOS 4.x and S5R4 (and possibly other systems), and the "exec()" code often done in the kernel, know about object or executable image files. This general model isn't unique to UNIX. For example: RSX-11 implements the "container" level in the Files-11 ACP, which is a somewhat privileged process running in user mode, as I remember, to which messages are sent when certain QIO functions are performed; it's basically an array of 512-byte blocks, rather than bytes, but it's still unstructured. The structure is provided by libraries running in user mode which perform those QIO functions to talk to the Files-11 ACP. F11ACP does provide some per-file attributes, I think, that can be fetched and set via QIOs, but that it doesn't itself interpret; those are used by the user-mode libraries. VMS is, I think, similar (although I think the ACP was replaced by the "extended QIO processor", which isn't a process receiving messages but is directly called, for performance reasons), although RMS runs, as I remember, in executive rather than user mode. Dunno if user-mode programs can, if they choose, get direct access to the "container" via QIOs or not. I think MS-DOS provides a generally-accessible "container" level as well, with structuring done above that level and suspect OS/2 does the same. Amoeba's Bullet file server, from what I can tell, also implements containers without imposing or providing any structure on the contents. Multics also provides containers, i.e. segments, at the lowest level. A lot of the complaints about UNIX seem ultimately either to be that it doesn't provide enough higher-level mechanisms that implement structured objects, or that the lowest level is too accessible. The former complaint is, I think, a fair one in many cases - but that doesn't say that providing unstructured containers is intrinsically a Bad Idea. The latter complaint strikes me as similar to the complaints that the instruction sets of modern machines are too low-level. Many complaints about a "semantic gap" seemed to ultimately miss the fact that there is an *intrinsic* semantic gap between doped silicon and high-level languages, and that the debate was really over the extent to which you filled in that gap with microcode and hardware as opposed to compilers and run-time libraries. There is room for a debate as to which parts should be filled in below the instruction set and which parts should be filled in above the instruction set, but that issue seems generally best resolved by looking at the performance, security, transparency, and development cost implications of various choices, not by looking at it as a philosophical issue. Similarly, there's a "semantic gap" between magnetized domains in iron oxide (or whatever) and data structures, but the layers at which that semantic gap should be filled in seem generally best resolved by looking at performance, security, transparency, and development cost issues, not philosophical issues. (E.g., by putting stuff at lower levels you can make changes to the implementation transparent to stuff at higher levels, and make it more secure if stuff at lower levels is "protected" while stuff at higher levels isn't. However: that doesn't necessarily reduce development costs - *somebody* has to fill in various parts of the aforementioned semantic gap in any case, and the question is which choice of where to fill it in makes it easier or means you have to do it fewer time; it doesn't necessarily increase performance.) To go back to the question you brought up earlier, the new "filesystem" module could provide those complex semantics atop a raw disk or partition, or could provide them atop a "container" file provided by some lower-level "filesystem" module. I've not seen any indication that there's some obvious universally "right" choice - nor have I seen any indication that the latter choice is obviously "wrong", as some folks flaming UNIX or, say, Plan 9 seem to think.