On architecture transparency in operating systems

Proceedings of the Tenth International Conference on Aspect-Oriented Software Development

Hofer

Schröder-Preikschat

et al. 2011

Self Cite

The domain of operating systems has often been mentioned as an "ideal candidate" for the application of AOP; fundamental policies we find in these systems, such as synchronization or preemption, seem to be inherently cross-cutting in their implementation. Their clear separation into dedicated aspect modules should facilitate better evolvability and -the focus of this paper -configurability. Our experience with applying AOP to the domain of highly configurable embedded operating systems has shown, however, that these advantages can by no means be taken for granted. To reveal maximum configurability of central system policies, aspects and their potential interactions with the system have to be taken into account much earlier, that is, "from the very beginning". We propose the analysis and design process of aspect-aware development, which leads to such an "aspect-friendly" system structure and demonstrate its feasibility on the example of CiAO, an AUTOSAR-OS-compliant operating system that provides configurability of all fundamental system policies by means of AOP.

Section: Introductionmentioning

confidence: 99%

Aspect-aware operating system development

Proceedings of the Tenth International Conference on Aspect-Oriented Software Development

Hofer

Schröder-Preikschat

et al. 2011

Self Cite

“…The Cyg_Mutex constructor ( Figure 3) is a typical example. Only 4 of the 27 code lines are dedicated to the plain mutex implementation (lines 1, [3][4]27). The remaining parts are occupied by one cross-cutting concern (namely tracing of function entries and exits, lines 2 and 26) and four configuration options (namely the different versions of the priority inversion protocol to use, lines 5-25).…”

Section: Using Aspects In the Ecosmentioning

confidence: 99%

“…As tracing is a typical development aspect, 4 we focus in the following on the refactored implementation of the more OS-specific and cost-critical kernel instrumentation and interrupt synchronization concerns. Before/after advice is used to superimpose the invocation of Cyg_Scheduler::lock()/unlock() into the execution 5 of all kernel functions that require synchronization.…”

Section: Refactoring Cross-cutting Concernsmentioning

confidence: 99%

“…Nearly ten years after its first presentation [22] and five years after its first application to operating systems [4,7], it is still a controversial question whether Aspect-Oriented Programming (AOP) provides a real benefit for the development of operating system kernels. Many OS developers have a sound skepticism regarding the suitability of high-level paradigms, such as AOP, for the systemlevel development problems they have to solve in their daily work.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

A quantitative analysis of aspects in the eCos kernel

Proceedings of the 1st ACM SIGOPS/EuroSys European Conference on Computer Systems 2006

Scheler

Tartler

et al. 2006

Self Cite

Nearly ten years after its first presentation and five years after its first application to operating systems, the suitability of AspectOriented 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.

“…The example is taken from the PURE operating system family 2 [2], which aims to support applications in the area of deeply embedded systems by providing fine-grained configuration capabilities. These configuration capabilities even include the configurability of certain architectural properties at compile time [1]. Here we will concentrate on the synchronization and concurrency aspect of device drivers.…”

Section: Example: Pure Device Driversmentioning

confidence: 99%

Using AOP to develop architectural-neutral operating system components

Spinczyk

Proceedings of the 11th Workshop on ACM SIGOPS European Workshop

2004

Self Cite

The architecture of an operating system, e.g. micro kernel or monolithic kernel, is usually seen as something static. Even during the long lasting evolution of operating system code it is extremely hard and, thus, expensive to change the architecture. However, our experience is that architectural evolution is often required and an architecture-neutral way to develop operating system components should be found. After analyzing why architectural flexibility is so difficult to achieve, we propose Aspect-Oriented Programming (AOP) as a solution. An example from the PURE OS family, which is implemented in an aspect-oriented programming language called AspectC++, will demonstrate the usefulness of the approach, which allows to separate the code that implements architectural properties from the core functionality.