Scout is an operating system designed for information appliances such as set-top boxes, or file- and web-servers. It is implemented in C [57], founded on a modular structure and built around the path abstraction which makes it suitable for the communication-oriented nature of appliances. The current system supports both best-effort and soft realtime scheduling. It is optimized for the needs of appliances and, at present, does not support multiple address spaces, protection domains, or shared-memory multiprocessors.
The reason for limiting the initial realization of Scout to simple uniprocessors is twofold. First, we expect that many appliances will not require more than what is currently provided by Scout. This is a direct consequence of the characteristics of appliances: they are specialized and often relatively small. Thus, shared memory multiprocessors and multiple protection domains are unlikely to be a requirement of many appliances.
Second, simplifying the structure of Scout allows us to focus on the intrinsic issues of communication-oriented systems. For example, it allows designing the path abstraction without worrying about how well it would be supported by the protection mechanisms of current hardware. This is a valid approach since it may be desirable and reasonable to change current hardware abstractions in response to the needs of communication-oriented systems. On the other hand, this approach bears the danger of conjuring up abstractions that have no hope of ever being able to run efficiently in a more complex system. While this danger exists, we have no reason to believe that this is the case for the Scout system presented in this chapter. Indeed, as the system is developed, informal arguments are presented as to why and how it could be extended to more complex environments.
With the above considerations in mind, it should be no surprise that conformance with standard programming interfaces, such as POSIX [94], is not a primary goal of Scout. An understanding of how existing interfaces support or interfere with the needs of a communication-oriented system could be useful, but is a secondary issue. In contrast to the internal programming interfaces, the external communication protocols are considered a given. This is not to say that existing protocols are sufficient or that they could not be improved upon, but it does mean that Scout must be capable of supporting existing, wide-spread protocols such as the Internet's TCP and IP protocols.
Before going into the details of Scout, it is useful to discuss the various epochs in a Scout system that are illustrated in Figure 10. The first epoch occurs when individual modules are implemented by a programmer. At a later time, the system designer decides what kind of paths are likely to be important to system performance. For those, path transformations can be implemented as described in Chapter 2. Once these are realized, the desired functionality for a particular information appliance is chosen by selecting the appropriate modules and connecting them into a module graph. At the same time, the designer can also specify complete path transformation rules (i.e., pick the appropriate path transformations and associate them with the proper guards). When this is all done, the system (kernel) is built. All steps mentioned so far are considered to occur during build time. In contrast, runtime covers all the steps that occur after the system has been booted on the target machine. During that time, paths may be created, used, and destroyed.
