Next, my prejudices. I am a strong supporter of research into the use of open implementation for operating systems. Several of my students are hard at work developing OI demonstrations and designing OI tools. (Actually, they would emphasize their interest in flexibility rather than OI, but there are strong similarities.) Thus, I am unlikely to conclude that this is all nonsense.
Open implementation is not new. That is, the ability of clients to modify a service implementation has a long, and somewhat troubled, history. Therefore, we need not focus on whether openness (in the sense of the paper) is a good thing, but rather on how to provide a framework for it. Such a framework should define disciplined openness to assure some measure of safety. It should be the basis for implementation strategies that reduce (or eliminate?) performance penalties. Perhaps most importantly, it should broaden our understanding of how we should use openness.
I claim that open implementation is not new. Consider, for example, DOS. While hardly a lesson in disciplined design, it clearly demonstrates the value of allowing clients to modify a service implementation. In its early days, almost all successful applications modified DOS's interrupt vector table to achieve acceptable performance. Word processors changed the screen management structure, databases wrote directly to the disk and hardware devices appropriated interrupts. Unfortunately, since there was no framework for these modifications, there were frequent conflicts.
The separation of concerns methodology also appears frequently. Consider a modern automobile. Its functionality interface defines the things a driver can do (turning the steering wheel, pressing the gas peddle, etc.). Its meta-interface is exported by the connector where a mechanic can plug in a diagnostic computer. The mechanic can query the automobile's state and can change function implementations (adjust the ignition timing, alter transmission shift points, etc.). If the mechanic abides by the rules, the functional interface will continue to perform properly; if not, not.
The key, then, is how to establish and enforce rules for the meta-interface. (Several other participants have made similar comments.) Issues of scope and system integrity are critical as, I believe, is the need to preserve the semantics of the functional interface. (Changing the transmission so that shifting to D made the car go backwards would be a bad idea!) This may also help us decide what can be exported through the meta-interface. If it can't be protected, it should probably not be exported.
Defining a structure for open implementations should let designers address performance issues. For example, as the paper notes, operating systems can be made open by implementing services at user-level. However, the resulting delays in crossing protection domains severely limit performance. However, at Notre Dame, we wanted an open implementation of system services that avoided this penalty. With the dual interface model in mind, we were able to propose a mechanism that preserves protection, respects scope and substantially improves invocation times.
In summary, I believe that the open implementation model is an attractive tool for dealing with flexibility. It captures deviations from the black box architecture that have typified actual systems but that have been omitted from their models. However, the open implementation model is young. It has been carefully analyzed in the abstract, but generally has been applied retrospectively. Actual experience has been limited to languages. To determine how much value it has, we will have to evaluate a variety of systems whose designs are based on this model. Only then will we be able to establish a common understanding of disciplined flexibility.
Back to Alphabetical List of Responses
(Last Revised October 1994)