Abstract not found

Nearly ten years after its first presentation and five years after its first application to operating systems, the suitability of Aspect-Oriented Programming (AOP) for the development of operating system kernels is still highly in dispute. While the AOP advocacy emphasizes the benefits of AOP towards better configurability and maintainability of system software, most kernel developers express a sound skepticism regarding the thereby induced runtime and memory costs: Operating system kernels have to be lean and efficient. We have analyzed the runtime and memory costs of aspects in general, on the level of µ-benchmarks, and by refactoring and extending the eCos operating system kernel using AspectC++, an AOP extension to the C++ language. Our results show that most AOP features do not induce a intrinsic overhead and that the actual overhead induced by AspectC++ is very low. We have also analyzed a test case with significant aspect-related costs. This example shows how the structure of the underlying kernel can have a negative impact on aspect implementations and how these costs can be avoided by an aspect-aware design. Based on this analysis, our conclusion is that AOP is suitable for the development of operating system kernels and other kinds of highly efficient infrastructure software.

Abstract. This paper presents work in progress on the C4 toolkit, which is designed to bring AOSD techniques to system software written in C and which we have used for introducing aspects into the Linux 2.6 kernel. The design of our toolkit focuses on addressing key concerns raised by system software developers when handed a new programming paradigm: readability, compatibility, performance, and the preservation of existing development workflows. By addressing these concerns, we believe our toolkit can bring the benefits of AOSD techniques to any large and complex program written in C. 1

Domain-specific language and compiler extensions can significantly reduce the complexity of systems, especially when written in C or C++. However, instead of the current variety of ad-hoc implementation strategies, which include preprocessor macros, C++ templates, and custom-built language processors, system builders need a uniform and general facility for realizing their own extensions. In this paper, we argue that macros can provide this solution, as they provide a concise specification of how to transform a program at compile time. We develop the requirements for a suitable macro facility, outline the structure of the corresponding macro processor, called xtc for eXTensible C, and explore the implications of starting to build it. We conclude that only a tighter integration between system and language efforts can help us achieve the benefits of language and compiler extensibility and cope with the complexity of modern systems. 1 Systems Need... The utilization of programming language and compiler technologies in operating and distributed systems certainly is not new [2]; notable examples include the Pilot [13], Oberon [16], and SPIN [3] operating systems as well as the Fox Project’s network protocol stack [4]. Yet the vast majority of system builders continues to rely on C (or C++) instead of fully type-safe or functional languages. When they need additional expressive power, they tend to add their own, domain-specific idioms to the base language by using a variety of ad-hoc implementation strategies, including preprocessor macros, C++ templates, or even custom-built language processors. However, the unfortunate result is that existing language and compiler extensions are mutually incompatible and that new extensions are hard to realize. To illustrate the power of domain-specific language and compiler extensions and the range of implementation strategies, consider libasync [10] for building eventdriven distributed services, Capriccio [15] for building multi-threaded servers, and MACEDON [14] for building overlay networks. Common to these projects is that they all build on C or C++, that runtime support is not sufficient, and that they require language or compiler support. At the same time, they differ significantly in

K42 is an open-source scalable research operating system well suited to support systems research. The primary goals of K42’s design that support such research include flexibility to allow a multitude of policies and implementations to be supported simultaneously, extensibility to allow new policies and implementations to be readily added, and scalability to enable good performance for both small and large applications on both small and large multiprocessor systems. The goals are accomplished via key features including an objectoriented structure that allows specialized resource management implementations and policies on a per-resource, perapplication basis, implementation in user-level servers of much of the system functionality, and a sophisticated set of underlying services that provides a programming model for developing system software in a scalable and modular fashion. These characteristics make K42 an attractive framework for prototyping new operating system ideas. In addition, K42 has a sophisticated performance monitoring infrastructure allowing a thorough understanding of new ideas to be gained. The above framework combined with a consistent emphasis on scalability makes K42 well suited for high-end computing initiatives. In this paper, we describe the structure of K42 which contributes to the advantageous prototyping environment, and demonstrate how to utilize it by describing ongoing research efforts.

This paper evaluates aspect-oriented programming (AOP) as a first-class concept for implementing configurability in system software for resource-constrained embedded systems. To compete against proprietary special-purpose solutions, system software for this domain has to be highly configurable. Such fine-grained configurability is usually implemented “in-line” by means of the C preprocessor. However, this approach does not scale – it quickly leads to “#ifdef hell” and a bad separation of concerns. At the same time, the challenges of configurability are still increasing. AUTOSAR OS, the state-of-the-art operating-system standard from the domain of automotive embedded systems, requires configurability of even fundamental architectural system policies. On the example of our CiAO operating-system family and the AUTOSAR-OS standard, we demonstrate that AOP – if applied from the very beginning – is a profound answer to these challenges. Our results show that a well-directed, pragmatic application of AOP leads to a much better separation of concerns than does #ifdef-based configuration – without compromising on resource consumption. The suggested approach of aspect-aware operating-system development facilitates providing even fundamental system policies as configurable features.

Existing black-box adaptation techniques are insufficiently powerful for a large class of real-world tasks. Meanwhile, white-box techniques are language-specific and overly invasive. We argue for the inclusion of specialpurpose adaptation features in a configuration language, and outline the benefits of targetting binary representations of software. We introduce Cake, a configuration language with adaptation features, and show how its design is being shaped by two case studies. 1.

We describe the implementation of memory protection by means of aspect-oriented programming (AOP) in CiAO, an AUTOSARlike family of embedded operating systems. The use of AOP was originally motivated by the fact that memory protection is a crosscutting policy, which, furthermore, has to be configurable at buildtime in AUTOSAR. We learned, however, that besides switching between full protection and no protection, an AOP-based approach also makes it easy to apply completely different models of protection. For the domain of statically configured embedded systems, where certain failure scenarios can often be excluded by means of code analysis or even probability, this facilitates tailored and light-weight “pay-as-you-use ” protection strategies.

Abstract. We rationally reconstruct the core of the Coccinelle system, used for automating and documenting collateral evolutions in Linux device drivers. A denotational semantics of the system’s underlying semantic patch language (SmPL) is developed, and extended to include variables. The semantics is in essence a higher-order functional program and so executable; but is inefficient and limited to straight-line source programs. A richer and more efficient SmPL version is defined, implemented by compiling to the temporal logic CTL-V (CTL with existentially quantified variables ranging over source code parameters and program points; defined using the staging concept from partial evaluation). The compilation is formally proven correct and a model check algorithm is outlined. 1

the feasibility of an AOSD approach to