Several aspects of Scout bear similarities to the x-kernel and indeed often are refinements that derive from experiences gained with it [49]. An interesting question is whether it would have been possible to add the path abstraction to the x-kernel. The CORDS system effectively did that with a limited form of paths [105]. In this sense, it is possible. However, a problem with adding paths to existing systems is that oftentimes existing abstractions conflict, or at least interfere, with paths. For example, in the case of the x-kernel, there are session objects that serve the role of communication end-points. This is very similar to the view paths present to the programmer of a module, so this raises the question of how sessions are related to paths. In essence, adding paths to existing systems is likely to significantly complicate the programming model. This is true not just for networking subsystems such as the x-kernel. For example, UNIX has the notion of file- and socket-descriptors, or X11 has the notion of window-handles, all of which would cause similar conflicts. It is also the case that modules typically need to be aware of path construction to ensure paths can grow as long as desired and also to ensure proper semantics should a path not be able to grow as long as desired. Suppose a path is created for communicating data via TCP/IP. If, for some reason, IP cannot make a fixed routing decision at path creation time, then the path would have to terminate at the IP module. To maintain the semantics of the TCP/IP path, this might force IP to create small paths between IP and each network adapter, for example. In general, the path abstraction often significantly affects the logic with which objects are created and destroyed, meaning that cleanly integrating such changes in a system not designed for paths is likely to be difficult.
UNIX STREAMS [42] are superficially similar to Scout paths. A STREAM essentially consists of a sequence of modules that is terminated by a STREAM head at the top (beneath the user/kernel boundary) and by a STREAM end at the bottom (device-driver level). The sequence of modules in a STREAM is dictated by the user-level application, meaning that the modules cannot affect these routing decisions. The interface between STREAM modules is limited to a message-oriented, bidirectional interface. This limits applicability of STREAMS to relatively simple applications as more complicated interfaces, such as those required for the disk subsystem or window management, cannot be accommodated. STREAMS also do not appear to support packet classification. For this reason, STREAMS are typically very wide in the Scout sense. For example, a STREAM may represent a stack of networking protocols, but it could not (easily) represent an individual TCP connection.
Like Scout, the work presented by Kay supports the construction of optimized code paths [56]. Its approach is to introduce the notion of PathIDs, which are integer numbers stored in the lowest-layer header of a networking subsystem. These identifiers are allocated on a per-path basis and therefore allow to quickly identify the code-path that should be used to process an incoming packet. In Scout, this would be equivalent to short-circuiting the packet classification process presented in Section 3.4.1. In some cases it may be possible to implement PathIDs using existing networking protocols. For example, ATM has a field containing a virtual circuit identifier (VCI). If VCIs can be allocated on a per-path basis, then they can be used in lieu of an additional PathID field [26]. However, PathIDs are not a general path-abstraction like the one defined by Scout. For example, they do not provide a means to generate optimized code paths automatically [56]. Manually written code is likely to result in good performance, but it is also time consuming to generate and difficult to maintain such vertically integrated code. In fact, Kay suggests that the use of PathIDs should be limited to the rare occasions where having to maintain two parallel branches of source code is justifiable.
In academia, much of the current OS research focuses on run-time extensibility of operating system kernels. Examples in this area include the Exokernel [32], FLUX [36], SPIN [7], and VINO [92]. In contrast, Scout is targeted at communication-oriented information appliances where the need for dynamic extensibility of kernel software is less of an issue. This is because many appliances are expected to be of relatively static nature. Rather than through fine-grained extension of a running system, appliances are more likely to be upgraded either through complete replacement of the system software or through virtual machine environments as discussed in the next paragraph. This is not to say that dynamic extensibility could not have a place in information appliances. Indeed, the techniques developed by these research projects are applicable to Scout insofar that they are orthogonal to the modular structure and path abstraction around which Scout is centered. For example, Scout and its path abstraction could readily be implemented in a type safe language such as Modula-3 [13] or it could employ sandboxing [109] to ensure the safe execution of dynamically loaded native-code modules.
In industry, there is a wealth of operating systems that are increasingly targeted at network computers (NCs) which could be considered a form of information appliances. There is no universal agreement on what precisely an NC is, though the term typically implies a machine that is primarily used for communication. There appear to be three major approaches to supporting NCs:
The second approach is followed by systems such as Oracle's NCI and Windows CE. The former uses a NetBSD kernel as its foundation with a trimmed down X Windowing System as its user interface. Similarly, Windows CE is essentially a trimmed down version of the Win32 API. For these systems, it seems questionable whether they are flexible enough to support the wide range that information appliances are expected to cover (e.g., both depend on the presence of virtual memory hardware). It is also unclear how effectively these systems could meet the predictability requirements that may be present in many appliances. In essence, this approach attempts to leverage existing application software, whereas Scout attempts to define a new paradigm that is inherently well-suited for the needs of communication-oriented devices.
The third approach involves adapting existing embedded operating systems to support communication through the addition of Internet protocols such as HTTP [35], TCP, and IP. Examples in this class include OS-9, pSOS+, QNX, and VxWorks [48]. Such systems often have hard realtime support and are relatively small and modular. They also are compute-focused, so support for path-like abstractions is missing. In essence, this means that realtime support is limited to the process abstraction and does not extend to the I/O subsystems. As a result, they cannot provide the level of control for resource management from the source- to the sink-device the way Scout paths can. It is also the case that hard realtime support is not necessarily sufficient or appropriate for information appliances. As will be described in some more detail in Section 6.3.1, soft realtime scheduling is in many ways more challenging than hard realtime scheduling. This is primarily because soft realtime scheduling needs to be able to deal with overload in a graceful manner, whereas hard realtime systems are typically designed to guarantee the absence of overload. Such a conservative design may not be appropriate for information appliances since it would mean that resources may remain underutilized most of the time, making the appliance more expensive than strictly necessary. Another important difference is that most embedded operating systems approach the question of modularity by providing the most general type of interface, such as a POSIX.1 interface or a micro-kernel like messaging interface. In contrast, Scout modularity is aimed at providing the least number of minimal interfaces, which makes it possible to connect modules in many useful ways and sometimes in ways not anticipated by the developer of a module. This is also facilitated by the filter-like modules of Scout and the fact that modules are connected by low-overhead procedure calls.
Aside from the path abstraction and modular architecture, Scout uses a novel classification scheme that is both efficient and powerful. The scheme is also unique in that it can be explained independently of the networking context in which it is usually employed. This makes it possible to elevate the classification problem to a general mechanism. As a consequence, Scout uses classifiers not just at the network driver level, but wherever an appropriate path needs to be found based on the contents of a message. Of the many packet classifiers and packet filters that have been proposed in the past, none fit the requirements of Scout perfectly. For example, interpreted packet filters are generally not fast enough [113, 61]. The performance of DPF, a classifier that uses runtime code generation [30] has been reported to be impressive, but unfortunately makes it relatively slow to insert and remove existing filters or, as is the case for version 2.0, provides a language with limited expressiveness. The PathFinder classifier [5] also has competitive performance, but it is a rather complex engine which would make it less suitable for appliances with stringent memory requirements. A practical problem common to all but the Scout classifier is that they require writing the classifier predicates in a special language. In contrast, the partial classifiers of Scout can be implemented in C. This is advantageous since it means that the data structures used by the module's packet processing code can also be used by the classifier. This greatly reduces problems due to inconsistencies in the packet descriptions, for example. Finally, the Scout classifier is powerful since the partial classifiers are implemented in a universal language. The only constraints on their complexity are due to performance and the desire to keep them side-effect free so that they can be short-circuited when an explicit PathID is present in a packet.