This paper focuses on developing componentized systems software and how to build systems software which solve complex problems but which is both easy to configure and robust. This paper provides an overview of two implementing approaches: Knit toolset and OOP components linking strategy.
Alastair, Matthew, Leigh, Jay and Eric (2) introduce a new module language and toolset for managing systems components called Knit. Knit is based on units, a model of components in the spirit of the Mesa and Modula module languages. Knit provides features useful in the design and implementation of complex operating systems on Unix machine.
Based on Alastair, Matthew, Leigh, Jay and Eric’s discussion, Figure 1 illustrates the Knit linking model atomic units, which a system can link together to form compound units. A compound unit contains a set of imports (the top part of the outer box) that can be propagated to the imports of units linked to form the compound unit. The compound unit explicitly specifies exports and imports are to be propagated. Because all connections are explicitly specified, arrows can connect import and exports with different names, allowing each unit to use locally meaningful names without the danger of clashes in a global namespace. The imports of the linked units that are not satisfied by imports of the compound unit must be satisfied by linking them to the exports of other units within the compound unit. The example in Figure 1 links the previous example unit with another unit that logs requested URLs. The original serve web function is wrapped with a new one, serve_logged, to perform the logging. The resulting compound unit still requires serve_file and serve_cgi to be provided by other units, and also requires functions for manipulating files. The compound unit’s export is the logged version of serve_web.
Figure 1: A compound unit
An alternate way of implementing components linking in Windows operating system is to use an object-oriented language or framework. In this approach, the links among components are defined by arbitrary code that passes object references around. This is the view of components implemented by object-based frameworks such as COM. Figure 2 shows a common visual representation of a software object: Everything that the software object knows (state) and can do (behavior) is expressed by the variables and the methods within that object. The object’s variables make up the center, or nucleus, of the objects. Methods surround and hide the object’s nucleus from other objects in the program. This conceptual picture of an object – a nucleus of variables packaged within a protective membrane of methods – is the ideal that designers of object-oriented systems strive for. Linking with objects includes specific linking instructions that connect each object’s global variables to its sharing nucleus. Symptoms of misusing objects as components include the late discovery of errors, difficulty in tracing the source of link errors, a performance overhead due to virtual function calls, and a high programmer overhead in terms of manipulating reference counts. Code for linking components is intermingled with regular program statements, making the code difficult for both humans and machines to analyze. Even type checking is of limited use, since object-based code uses many dynamic type checks (i.e., downcasts) to verify that components have the expected types, and must be prepared to recover if this is not so. These problems all stem from using a dynamic mechanism (objects) to build systems in which the connections between components change rarely, if ever, after the system is configured and initialized.
Figure 2: Object-Oriented Framework
Both Knit and Object-Oriented Framework systems provide a method for components in an efficient way. The Object-Oriented approach start with object files that are linked to create the program. It allows programmer to provide the collection of files to the linker as a package of objects. This makes grouping components more flexible. However, it reduces the operating system performance. Knit gives a better solution on the components multi-implementation on the same interface, but programmer has difficulties on the future linking changes. Because all units are linked to each other explicitly, whenever a component changed, the whole system links need to be re-evaluated, if some cases, they must re-link.
In conclusion, Knit brings strong analysis and optimization techniques to bear on componentized systems software. It helps to detect deadlocks and unsafe locking, reduce abstraction overheads and flatten layered implementations. All of these tasks require the well-defined component boundaries and static linking information. Object-based component language provides better help to the programmers in ensuring that components are linked together properly. Objects are essentially reusable software components that model items in the world. Object-oriented programs are often easier to understand, correct and modify.