Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: VMS vs. UNIX file system Message-ID: <69166@sun.uucp> Date: 20 Sep 88 18:16:36 GMT References: <411@marob.MASA.COM> <3597@encore.UUCP> <3438@crash.cts.com> <1210@unmvax.unm.edu> Sender: news@sun.uucp Lines: 47 > But standard I/O runs in user mode, not in a more-priviledged mode. What > you consider the OS to be is not what it in fact is. Help stamp out ontology in our lifetimes! "In fact", the OS "is" what it somebody defines it to be. I see no reason to define it in such a way as to exclude code running in user mode; in fact, a good reason to define it to *include* that code is that it helps people realize that "putting something into the OS" need not be synonymous with "putting it into the kernel". > A good working description of OS is that part of the system which the > arbitrary user cannot rewrite and use in lieu of the distributed code. An equally good, if not better, working description is "that part of the system that comes on the tape that the vendor calls the operating system distribution tape". If you want a term that describes that part of the system that the user can't replace, "kernel" is an OK one, although systems such as VMS run some of that part of the system in modes less privileged than kernel mode. "OS" is somewhat of a poor one, because it does not "in fact" correspond to the way "operating system" is generally used. "OS/360" includes a bunch of stuff not run in supervisor state; for instance, as I understand it, the access methods actually run in problem state, and build channel programs and issue SVCs to get them started. Lacking any better term, I would opt for "privileged portion of the OS" or some such term. > But...the user can't necessarily replace RMS without getting to write > his own CHME dispatch table, something the kernel is not likely to let > him do. This depends on what you mean by "replace". Under RSX-11, you can presumably "replace" RMS, in the sense of having a package that does the same general sort of function, without being able to get at a more privileged mode. If an RMS-like package doesn't require QIOs that can be run only from executive mode, you could do the same under VMS (although I wouldn't put it past DEC to have stuck in executive-mode-only QIOs which RMS uses). The point is that lots of people confuse "OS" with "kernel", and I suspect many of them either advocate putting features into the kernel, express alarm at the prospect of features being put into the kernel, or think features are implemented in the kernel because they confuse "OS" with "kernel".