lovejoy@alc.com (Alan Lovejoy) (01/10/91)
In article <10813@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >I realize this is probably not the proper newsgroup for this >discussion, but there is no comp.sys.misc and this is where >the issue came up. If anyone can think of a better venue, >let me know. We need "comp.sys.design.philosophy" for discussion of topics like this one. "comp.arch", "comp.lang.misc" and "comp.os.theory" are not abstract enough. Actually, the USENET topic taxonomy has many similar problems. Someday, a more intelligent mechanism/protocol should be...evolved...for BBS topic creation and maintenance. A society's perception of reality is VERY strongly influenced by its taxonomy of concepts and topics. It's not that there is some "optimum" or "best possible" taxonomy--there isn't. In fact, it's the very tendency to think that the currently-in-use taxonomy is "the best" that can cause so much trouble! The "right" taxonomy of concepts and/or topics depends strongly on what the taxonomy is being used for, and on the goals and purposes of the individual or society that is using it. It may be that multiple conjoint but inconsistent taxonomies should be employed simultaneously. >ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >> [...] >> Consider what an operating system is supposed to do. Different >> people have lots of different ideas on this, but among the most >> important design principles that I can think of are: >> >> 1) Shield the application program from hardware dependencies, >> and variations in system configurations. >> 2) Provide a standard interface to services that allow >> transfer of information between applications. >> [...] > >The most important operating system features are these: > > A) Intercept and authenticate all requests for resources. This > is a security issue and should be _the_ primary concern of an > operating system (even a single user system - after all, how > can someone protect himself from viruses if there is no > security mechanism in the system?). MS-DOS has no capability > in this respect _at_all_. UNIX is little better. Having said > this about UNIX, I expect a flurry of UNIX cultists to flame > about how UNIX really is secure after all. That is one of the > flaws about UNIX - it _pretends_ to have security and many > people believe the pretense. Security is merely a type of error-prevention and correctness verification. Verification of correctness should be done--whenever possible--by guaranteeing that errors cannot arise in the first place. An optimal design doesn't have any error states. A transition to an error state cannot happen if there are no error states. In the real world, of course, practical considerations and mutually incompatible requirements usually lead to systems/machines that simply must have error states. In those cases, explicit checks for those states should be designed in to the system. Correctness is ultimately defined by the user. If the system does what he wants, it works correctly. Otherwise, it doesn't. Complete security can be provided by complete virtualization of all aspects of the system. Virtualization dynamically customizes--redefines--the semantics of system functions. If the system function semantics are redefined so that the system does what the user wants in that context, then virtualization provides correctness--and therefore security. Obviously, security depends upon the ability of the user to dynamically change what the system does (e.g., sometimes it will delete a file, other times it won't; sometimes you can access a memory location, other times you can't, etc.). The prime directive of any system is to work correctly--that is, do what the user wants. Security--as it is normally conceived--is just a special case. The difference between MS-DOS, MacOS, AmigaDOS, OS/9, UNIX, VMS, OS/360, MVS, VM, MACH, Multics and so forth in respect to functional correctness--and therefore security--are merely matters of degree, especially as regargds the extent to which system function semantics are dynamically redefinable as functions of the current environment/context. In that light, security is merely a feature--not a fundamental raison d'etre for the existence of an OS. After all, an emebedded system with no formal "operating system" can provide very high security--probably much more than any system with a standardized/general purpose operating system could. Also, the degree to which a system is "secure" does not correlate strongly with the degree to which it qualifies as an operating system. That should not be true of anything which is a fundamental, defining, motivating quality. An operating system is based on, defined and motivated by the services it provides and the functions it performs. An operating system kernel is that code which most directly interfaces with the system hardware in order to virtualize, generalize, standardize or simply modularize access to the system hardware. Typically, that includes exception/interrupt handlers, device drivers, program loaders, task schedulers and memory managers. Operating systems that provide "pluggable" file systems, device drivers, memory managers, program loaders and/or exception/interrupt handlers merely provide another level of virtualization. In effect, they are meta operating systems. > B) For all resource requests that have been authenticated, schedule > the resource to satisfy the request. Again, MS-DOS doesn't have > multi-processing so scheduling isn't done at all. UNIX (and most > other operating systems) have an advantage here. But, the versions > of UNIX that I've seen are pretty poor at scheduling. > >The things you mention are important, but are less so than the two just >given. In particular, most of the features you mention should probably >not even be in the system kernel itself. Device drivers, for example >should be thought of as server processes that can be swapped out of memory >entirely if the device has no active requests against it. > >> [...] >> 3) Implement other useful services that application programmers >> find themselves reinventing. > >I delayed this discussion because, of all the things on your list, this >is the one I'm not sure should be done by the operating system _at_all_. >There are, for example, many systems in which all I/O is (normally) >done through a feature-rich "record manager". This provides many file >and record types which are very useful to database type applications, >etc.. Unfortunately, they are so feature-rich that they slow I/O >down considerably when you use them. But, since it's usually _very_ >hard to get around the record manager, you're stuck with it. > >Personally, I think the operating system should provide simple, fast, >low-level functionality and the "useful services" that you are talking >about should be done as servers and/or utilities and libraries. In >other words, the user who doesn't need or use these features shouldn't >give up system performance because of their presence. > >J. Giles All you are really asking for is greater modularity/granularity of function, polymorphic pluggability of modules/components, and powerful abstraction mechanisms. It is this same desire to "downsize" that motivates RISC and MISC CPU designers, and modern OOP/functional languages. The idea is that most functionality should be defined by the user using the abstraction mechanisms, instead of built-in by the vendor/original designer. Amen. -- %%%% Alan Lovejoy %%%% | "Do not go gentle into that good night, % Ascent Logic Corp. % | Old age should burn and rave at the close of the day; UUCP: lovejoy@alc.com | Rage, rage at the dying of the light!" -- Dylan Thomas __Disclaimer: I do not speak for Ascent Logic Corp.; they do not speak for me!