From: shearerje_at_comcast.net
Date: Sun Jan 11 2004 - 22:22:28 PST
“HYDRA: The Kernel of a Multiprocessor Operating System” was first published (received) in June of 1973, four months before “Protection and the Control of Information Sharing in Multics”, and it looks like the authors were completely unaware of the Multics effort. HYDRA is described as both the kernel of an operating system and a toolset for developing operating systems. However, I found the author’s use of the term “operating system” in this context to be dissatisfying. The paper envisions a multitude of operating systems on a single machine built on the single HYDRA kernel. This sounds to me more like a description of different shells as, for example, CSH, BASH, and other shells run on the UNIX kernel. But then the paper discusses alternative file systems in each of these “operating systems”. If the file systems are not compatible between these operating systems, then users cannot share files across their environments. On the other hand, the example at the end of the paper could just have easily bee
n written in ORACLE and offered the same access control, so maybe the authors are using the term “file system” to refer to a higher level database layout rather than the fundamental memory access mechanism that I expected it to mean. My conclusion is that the paper discusses as one subject what are today considered several distinct subjects, and that it does this using common terms in strange ways. That said, there are several specific points in the paper I would like to address in the following paragraphs.
Hierarchy: The paper asserts “we reject (strict hierarchical layering) as a global design criterion” for fear that it will “severely limit flexibility”. But the whole point of the strict hierarchy in the THE system was to provide layers of abstraction so that the user at the application layer would have MORE flexibility. Further, the authors failed to demonstrate either that they successfully avoided all forms of hierarchy, or that this bought them anything in terms of flexibility. The discussion of templates and the expansion of rights was interesting, but the stated issues were solved, in my opinion, much more satisfactorily in the Multics paper. I thought the assertion “protection is a mechanism; security is a policy” was insightful, and that a failure to distinguish these concepts can lead to a “succession of increasingly privileged system components”, but it is not clear to me that this is necessarily the inevitable result of a hierarchical design, only of poorly implemented security policy.
Object types: The paper discusses three primary object classes; procedures, local name spaces, and processes. It’s remarkable how accurately these resemble C++ classes, objects, and threads. The code for a class resides in memory exactly once as in the “procedures”, the class attribute data is unique for each instantiated object of the class as in the “local name spaces” for exactly the same reasons as discussed in the paper, and both C++ threads and the paper’s “processes” are the smallest entities which can be independently scheduled for execution. However, the use of a single “type part” for each object seems restrictive. Has polymorphism been excluded? I was also surprised the CALL and RETURN applied to procedures, not processes. Thus, they are not the same as fork and quit/join.
This archive was generated by hypermail 2.1.6 : Sun Jan 11 2004 - 22:22:34 PST