Aspect-Awareness in the Development of Configurable System Software

276 Pages·2009·3.17 MB·English

by  Daniel Lohmann

Aspect Awareness in the Development of
Configurable System Software
—
Aspektgewahrheit bei der Entwicklung
konfigurierbarer Systemsoftware
Der Technischen Fakultät der
Universität Erlangen-Nürnberg
zur Erlangung des Grades
D -I
OKTOR NGENIEUR
vorgelegt von
Daniel Lohmann
Erlangen — 2008
Als Dissertation genehmigt von
der Technischen Fakultät der
Universität Erlangen-Nürnberg
Tag der Einreichung: 27.10.2008
Tag der Promotion: 30.03.2009
Dekan: Prof. Dr.-Ing. Johannes Huber
Berichterstatter: Prof. Dr.-Ing. Wolfgang Schröder-Preikschat
Prof. Dr.-Ing. Olaf Spinczyk
Prof. Dr.-Ing. Jörg Nolte
Abstract
More than 98 percent of the worldwide annual production of microprocessors ends
up in embedded systems – typically employed in goods of mass production, like cars,
appliances, or toys. Such embedded systems are subject to an enormous hardware-cost
pressure. System software for this domain has to cope not only with a broad variety of
requirementsandplatforms,butespeciallywithstrictresourceconstraints. Tocompete
againstproprietarysystems (andtherebytoallow forreuse), asystem-softwareproduct
line for embedded systems has to be highly configurable and tailorable. However, this
flexibility has to be provided in a way that meets the strict resource constraints.
Thestateoftheartfortheoverhead-freeimplementationoffine-grainedconfigurability
in system software is conditional compilation with the C preprocessor. However, this
approach leads to scattered and tangled code and does not scale up. At the same time,
thedemandsonconfigurabilityofsystemsoftwarearestillincreasing. AUTOSAROS,a
new industry standard for automotive operating systems, requires configurability of even
fundamental architectural system policies, such as protection and isolation strategies.
This thesis evaluates aspect-oriented programming (AOP) as a first-class concept for im-
plementing configurability in resource-constrained systems. It shows that a well-directed,
pragmatic application of AOP leads to a much better separation of concerns in the imple-
mentationofconfigurablesystemsoftware–withoutcompromisingonresourcethriftiness.
Moreover, the suggested approach of aspect-aware operating-system development facilitates
providing even fundamental architectural policies as configurable features.
The suitability of AOP is evaluated with state-of-the-art operating systems from the
embedded-systems domain. The practicability of aspect-aware operating-system devel-
opment is validatedby the design anddevelopment of the CiAOoperating-system family,
which is the first operating system that has been designed and developed with AOP
concepts from the very beginning. CiAO combines a competitive implementation of the
AUTOSAR-OS standard with a highly configurable architecture.
i
ii
Acknowledgments
Many people have supported me in writing this thesis and deserve to be mentioned here.
It seemsto be commonpractice tomention them ina strictly hierarchicalorder (not to
say top-down) starting with the supervising professors. However, as I shall point out in
Chapter 3, this thesis follows a bottom-up approach.
Soletmestartwiththedomestiquesofscience–thestudentswhowrotestudyanddiploma
theses under my supervision, in which they evaluated some of my crazy ideas: GEORG
BLASCHKE, CHRISTOPH ELSNER, WANJA HOFER, FABIAN SCHELER, JOCHEN STREICHER,
and REINHARD TARTLER. Boys, it was fun working with you – and still is! Given that five
of the six of you have continued with science afterwards (a fact I am admittedly a bit
proud of) and have even become colleagues, it can’t have been too bad :-)
Speaking of colleagues (and continuing bottom-up): Many thanks go to MEIK FELSER,
RÜDIGER KAPITZA, and CHRISTIAN WAWERSICH, who shared with me the good times and
the bad times of thesis writing. Christian, I am really happy that you finished the thing
before me. The party ain’t over ’till “The Fat Lady Sings”!
A significant part of the CiAO implementation was done during my time at the University
of Victoria, BC, Canada. I wish to thank YVONNE COADY and especially CHRIS MATTHEWS,
who supported me in all “aspects” of life during that time, and FIONN YAXLEY and CALEY
CAMPBELL, who did the same in all aspects of living.
Many thanks go to FRANK BELLOSA, who taught me the hidden politics of science during
his post-doc time in Erlangen, and to JÜRGEN KLEINÖDER, who has been doing the same
with respect to the hidden secrets of administration.
So we have passed the post-doc level and eventually arrived at the supervising professors:
My special thanks go to OLAF SPINCZYK and WOLFGANG SCHRÖDER-PREIKSCHAT. It was
Olaf who invited me to join Wosch’s group in Erlangen after we met at AOSD 2003 in
Boston. Together, wecarried out alot of great research– which wouldnever have been
possible without the open, inspiring and encouraging atmosphere Wosch cultivates within
his group.
Finally, I wish to thank those people whose support was neither bottom-up nor top-down,
but just there when I needed it. BERNHARD GABLER did a great job of proofreading and
language polishing. But above all there was my wife Katja, who took care of me and
raised my spirits – again and again.
Erlangen, April 2009
iii
iv
Contents
1. Introduction 1
1.1. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Purpose of This Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Title and Objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Background,Context,andStateoftheArt 9
2.1. System Software for Embedded Systems . . . . . . . . . . . . . . . . . . . 11
2.1.1. Properties of Embedded Systems . . . . . . . . . . . . . . . . . . . 11
2.1.2. Hardware for Embedded Systems . . . . . . . . . . . . . . . . . . . 12
2.1.3. The Role of System Software . . . . . . . . . . . . . . . . . . . . . 14
2.1.4. The Role of Operating Systems . . . . . . . . . . . . . . . . . . . . 16
2.1.5. Implementation Techniques for Customizable Operating Systems . 18
2.1.6. From Customizing to Configuring of System Software . . . . . . . . 23
2.2. Software Product Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1. Concepts and Terminology of Software Product Lines . . . . . . . . 25
2.2.2. History of Software Product-Line Engineering . . . . . . . . . . . . 26
2.2.3. Specifying the Problem Space . . . . . . . . . . . . . . . . . . . . . 27
2.2.4. The Problem Space of Configurable Operating Systems . . . . . . . 29
2.2.5. Implementing the Solution Space . . . . . . . . . . . . . . . . . . 30
2.3. Aspect-Oriented Programming . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1. The Problem of “Crosscutting Concerns” . . . . . . . . . . . . . . . 33
2.3.2. Queue Example: Scattering and Tangling in a Simple Product Line 33
2.3.3. Dimensions of Crosscutting . . . . . . . . . . . . . . . . . . . . . . 35
2.3.4. Concepts and Terminology of Aspect-Oriented Programming . . . . 36
2.3.5. Queue Example: Solution Space Implementation with AspectC++ 38
2.3.6. History of AOP Languages . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.7. AOP in Operating Systems . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.8. AOP Critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4. Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
v
Contents
3. ProblemAnalysisandSuggestedApproach 47
3.1. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1.1. How Configurability Becomes Manifest in the Code – The eCos Case 49
3.1.2. Going Ahead – The Case for Configurable Architecture . . . . . . . 58
3.1.3. Problem Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2. Is AOP the Solution? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3. Suggested Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.3.1. Language Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3.2. Implementation Level . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3.3. Design Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4. Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4. LanguageLevel–AspectsDemystified: EvaluationandEvolutionofAspectC++ 67
4.1. General Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1.1. AOP Fundamentals: A Recap . . . . . . . . . . . . . . . . . . . . . 69
4.1.2. Requirements on an Aspect Language for System Software . . . . . 69
4.1.3. The Expected Cost of Aspects . . . . . . . . . . . . . . . . . . . . . 74
4.1.4. Aspect Languages for Embedded System Development . . . . . . . 76
4.1.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.2. Generic Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.2.1. Generic Advice – Motivation . . . . . . . . . . . . . . . . . . . . . . 81
4.2.2. ExtendingtheJoin-PointAPIforGenericandGenerativeProgramming 83
4.2.3. Example: Checking for Invalid Object Identifiers in AUTOSAR OS . 86
4.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3. AspectC++ Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.3.1. Code Generation of AC++ . . . . . . . . . . . . . . . . . . . . . . . 88
4.3.2. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.4. Discussion of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.4.1. Qualitative Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.4.2. Quantitative Effects . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.5. Further Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.5.1. AOP in Pure C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.5.2. Generic Advice in Other Aspect Languages . . . . . . . . . . . . . . 97
4.5.3. Aspect Language Overhead . . . . . . . . . . . . . . . . . . . . . . 97
4.6. Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5. ImplementationLevel–AspectsinAction: PracticingConfigurabilitybyAOP 99
5.1. Case Study “eCos” – Objectives and Study Design . . . . . . . . . . . . . . 101
5.2. Aspectizing the eCos Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.2.1. Refactoring Concerns into Aspects . . . . . . . . . . . . . . . . . . 102
5.2.2. The Cost of Large-Scale AOP . . . . . . . . . . . . . . . . . . . . . 107
5.3. Improving eCos Configurability by AOP . . . . . . . . . . . . . . . . . . . . 113
5.3.1. Turning Synchronization and Preemption into Optional Features . . 113
5.3.2. Adding a New Feature: The Kernel Stack Aspect . . . . . . . . . . . 115
vi
Contents
5.4. Discussion of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.4.1. The Implementation of Configurability by AOP . . . . . . . . . . . 117
5.4.2. Consequences for Aspect-Aware Operating-System Developement . 119
5.5. Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6. DesignLevel–CiAOAspects: Aspect-AwareOperating-SystemDevelopment 121
6.1. A Brief Overview of CiAO . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.1.1. Goals and Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.1.2. General Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.1.3. Kernel Personalities and Features . . . . . . . . . . . . . . . . . . . 125
6.1.4. Configuration of System Components, Abstractions, and Objects . . 125
6.2. CiAO Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.3. Aspect-Aware Development Idioms . . . . . . . . . . . . . . . . . . . . . . 128
6.3.1. Roles and Types of Classes and Aspects . . . . . . . . . . . . . . . . 128
6.3.2. Diagram Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.3.3. Loose Coupling by Advice-Based Binding . . . . . . . . . . . . . . . 129
6.3.4. Visible Transitions by Explicit Join Points . . . . . . . . . . . . . . . 132
6.3.5. Minimal Extensions by Extension Slices . . . . . . . . . . . . . . . 135
6.3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.4. Case Study “Continuation” . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.4.1. Continuation Features . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.4.2. Continuation Design . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.4.3. Implementation for TriCore . . . . . . . . . . . . . . . . . . . . . . 140
6.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.5. Case Study “Interrupt Synchronization” . . . . . . . . . . . . . . . . . . . 146
6.5.1. CiAO Interrupt Synchronization Models . . . . . . . . . . . . . . . 147
6.5.2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.5.3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.5.4. Interrupt Latency Comparison . . . . . . . . . . . . . . . . . . . . 156
6.5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.6. Case Study “CiAO-AS” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.6.1. Analysis Results – From Requirements to Concerns . . . . . . . . . 158
6.6.2. Development Results – From Concerns to Classes and Aspects . . . 162
6.6.3. Evaluation Results – From Configurations To Cost . . . . . . . . . . 164
6.6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
6.7. Discussion of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.7.1. Obliviousness Versus Awareness . . . . . . . . . . . . . . . . . . . . 168
6.7.2. AOP Critique – Revisited . . . . . . . . . . . . . . . . . . . . . . . . 168
6.8. Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
7. Summary,Conclusions,andFurtherIdeas 171
7.1. Summary and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
7.2. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
7.3. Further Ideas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
vii
Contents
A. Appendix: AspectC++ 177
A.1. Language Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
A.1.1. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
A.1.2. AspectC++ Grammar Extensions . . . . . . . . . . . . . . . . . . . 180
A.1.3. Join-Point Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
A.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
A.2.1. Observer Pattern with AspectC++ . . . . . . . . . . . . . . . . . . 182
A.2.2. Caching with AspectC++ . . . . . . . . . . . . . . . . . . . . . . . 184
A.3. AspectC++ Language Quick Reference . . . . . . . . . . . . . . . . . . . . 190
A.3.1. Syntax Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
A.3.2. Join-Point Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
A.3.3. Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
A.3.4. Advice Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . 190
A.3.5. Match Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
A.3.6. Predefined Pointcut Functions . . . . . . . . . . . . . . . . . . . . . 191
A.3.7. Join-Point API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
A.4. Around-Advice Implementation in AC++-0.9 and AC++-1.0PRE1 . . . . 194
A.4.1. Code Generation with AC++-0.9 . . . . . . . . . . . . . . . . . . 194
A.4.2. Code Generation with AC++-1.0PRE1 . . . . . . . . . . . . . . . . 196
B. Appendix: CaseStudy“WeatherMon” 199
B.1. WeatherMon Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
B.2. Designing for Configurability with AOP and OOP . . . . . . . . . . . . . . 203
B.2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
B.2.2. The OO Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
B.2.3. The AO Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
B.3. AOP and OOP Idioms for Configurability . . . . . . . . . . . . . . . . . . . 206
B.3.1. Issue 1: Working with Configuration-Dependent Sensor and Actua-
tor Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
B.3.2. Issue 2: Implementation of Generic Actuators . . . . . . . . . . . . 209
B.3.3. Issue 3: Implementation of Nongeneric Actuators . . . . . . . . . . 210
B.3.4. Design Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
B.4. The Cost of Configurability in Deeply Embedded Systems . . . . . . . . . . 213
B.4.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
B.4.2. Overall Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
B.4.3. Memory Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
B.4.4. Run-Time Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
B.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Bibliography 219
viii