CiAO: An Aspect-Oriented OS Family for Resource-Constrained Embedded - - PowerPoint PPT Presentation

ciao an aspect oriented os family for resource
SMART_READER_LITE
LIVE PREVIEW

CiAO: An Aspect-Oriented OS Family for Resource-Constrained Embedded - - PowerPoint PPT Presentation

CiAO: An Aspect-Oriented OS Family for Resource-Constrained Embedded Systems Daniel Lohmann Wanja Hofer Wolfgang Schrder-Preikschat Friedrich-Alexander University Erlangen-Nuremberg Jochen Streicher Olaf Spinczyk Technical University


slide-1
SLIDE 1

CiAO: An Aspect-Oriented OS Family for Resource-Constrained Embedded Systems

Daniel Lohmann Wanja Hofer Wolfgang Schröder-Preikschat

Friedrich-Alexander University Erlangen-Nuremberg

Jochen Streicher Olaf Spinczyk

Technical University Dortmund

CiAO is aspect-oriented

slide-2
SLIDE 2

wosch@cs.fau.de - USENIX 2009

2 2

Motivation: Embedded Systems

slide-3
SLIDE 3

wosch@cs.fau.de - USENIX 2009

3 3

Motivation: Embedded Systems

Goal: Reuse Scalability, Configurability, Tailorability

slide-4
SLIDE 4

wosch@cs.fau.de - USENIX 2009

4 4

Motivation: Configurability of eCos

slide-5
SLIDE 5

wosch@cs.fau.de - USENIX 2009

5 5

Motivation: Configurability of eCos

Kernel policies:

Synchronization Instrumentation Tracing PROTOCOL CEILING INHERIT DYNAMIC

Mutex

  • ptions:
slide-6
SLIDE 6

wosch@cs.fau.de - USENIX 2009

6 6

Motivation: Configurability of eCos

Kernel policies:

Synchronization Instrumentation Tracing PROTOCOL CEILING INHERIT DYNAMIC

Mutex

  • ptions:
slide-7
SLIDE 7

wosch@cs.fau.de - USENIX 2009

7 7

Motivation: Configurability of eCos

Kernel policies:

Synchronization Instrumentation Tracing PROTOCOL CEILING INHERIT DYNAMIC

Mutex

  • ptions:
slide-8
SLIDE 8

wosch@cs.fau.de - USENIX 2009

8 8

Motivation: Configurability of eCos

Base implementation:

Cyg_Mutex::Cyg_Mutex() { locked = false;

  • wner = NULL;

}

Cross-cutting concerns: 34 #ifdef-blocks spread over 17 functions and data structures in 4 implementation units

slide-9
SLIDE 9

wosch@cs.fau.de - USENIX 2009

11 11

Motivation: Configurability of OS

 Difficult to understand, maintain, evolve  Lack of encapsulation in the implementation  Tangling of many concerns in one implementation unit  Scattering across several implementation units

#ifdef hell

slide-10
SLIDE 10

wosch@cs.fau.de - USENIX 2009

12 12

Talk Outline

 Cross-cutting in Configurable System Software  Aspect-Oriented Programming (AOP) to the Rescue?  CiAO: Aspect-Aware OS Design  Evaluation: Suitability for Embedded Systems

slide-11
SLIDE 11

wosch@cs.fau.de - USENIX 2009

13 13

Talk Outline

 Cross-cutting in Configurable System Software  Aspect-Oriented Programming (AOP) to the Rescue?  CiAO: Aspect-Aware OS Design  Evaluation: Suitability for Embedded Systems

slide-12
SLIDE 12

wosch@cs.fau.de - USENIX 2009

14 14

AOP to the Rescue?

 AOP aids modularization of cross-cutting concerns

badly modularized well modularized concern

without AOP

slide-13
SLIDE 13

wosch@cs.fau.de - USENIX 2009

15 15

AOP to the Rescue?

 AOP aids modularization of cross-cutting concerns  It does so by means of aspects

badly modularized well modularized concern

without AOP with AOP aspect

slide-14
SLIDE 14

wosch@cs.fau.de - USENIX 2009

16 16

AOP – Short Introduction

 Encapsulation of (cross-cutting) concerns in aspects

aspect components

slide-15
SLIDE 15

wosch@cs.fau.de - USENIX 2009

17 17

AOP – Short Introduction

 Encapsulation of (cross-cutting) concerns in aspects  Aspects give advice to join points in the target system

aspect components

slide-16
SLIDE 16

wosch@cs.fau.de - USENIX 2009

18 18

AOP – Short Introduction

 Encapsulation of (cross-cutting) concerns in aspects  Aspects give advice to join points in the target system  Set of join points described

by a pointcut expression

aspect components pointcut

slide-17
SLIDE 17

wosch@cs.fau.de - USENIX 2009

19 19

AOP – Short Introduction

 Encapsulation of (cross-cutting) concerns in aspects  Aspects give advice to join points in the target system  Set of join points described

by a pointcut expression

aspect components pointcut

Obliviousness & Quantification

slide-18
SLIDE 18

wosch@cs.fau.de - USENIX 2009

20 20

AOP – AspectC++

 Extension to C++  Source-to-source weaver

http://www.aspectc.org C++ Sources AspectC++ Sources ac++ Woven C++ Code c++ Binary Program

01010001100 11011101001

slide-19
SLIDE 19

wosch@cs.fau.de - USENIX 2009

21 21

AOP – Why Can It Help?

 Inversion of caller–callee binding:

// traditional implementation void dingus() { …// do basic stuff #ifdef OPT_FEATURE thingy(); #endif } void thingy() { …// do optional stuff }

slide-20
SLIDE 20

wosch@cs.fau.de - USENIX 2009

22 22

AOP – Why Can It Help?

 Inversion of caller–callee binding:

// traditional implementation void dingus() { …// do basic stuff #ifdef OPT_FEATURE thingy(); #endif } void thingy() { …// do optional stuff } // AOP implementation void dingus() { // do basic stuff } advice execution(“% dingus()”) : after() { // do optional stuff }

slide-21
SLIDE 21

wosch@cs.fau.de - USENIX 2009

23 23

AOP – Why Can It Help?

 Quantification over multiple join points:

// traditional implementation void dingus_foo() { #ifdef OPT_FEATURE thingy(); #endif } void dingus_bar() { #ifdef OPT_FEATURE thingy(); #endif } void thingy(){ // do optional stuff }

slide-22
SLIDE 22

wosch@cs.fau.de - USENIX 2009

24 24

AOP – Why Can It Help?

 Quantification over multiple join points:

// traditional implementation void dingus_foo() { #ifdef OPT_FEATURE thingy(); #endif } void dingus_bar() { #ifdef OPT_FEATURE thingy(); #endif } void thingy(){ // do optional stuff } // AOP implementation void dingus_foo() { } void dingus_bar() { } advice execution(“% dingus%()”) : after() { // do optional stuff }

slide-23
SLIDE 23

wosch@cs.fau.de - USENIX 2009

25 25

Talk Outline

 Cross-cutting in Configurable System Software  Aspect-Oriented Programming (AOP) to the Rescue?  CiAO: Aspect-Aware OS Design  Evaluation: Suitability for Embedded Systems

slide-24
SLIDE 24

wosch@cs.fau.de - USENIX 2009

26 26

CiAO: Aspect-Aware OS Design

 Goal of the CiAO project:

Evaluate if AOP is suitable for the design of configurable embedded system software

  • Can AOP help to avoid #ifdef hell?
  • Is AOP efficient enough for the domain of embedded systems?
slide-25
SLIDE 25

wosch@cs.fau.de - USENIX 2009

27 27

CiAO: Aspect-Aware OS Design

 Goal of the CiAO project:

Evaluate if AOP is suitable for the design of configurable embedded system software

  • Can AOP help to avoid #ifdef hell?
  • Is AOP efficient enough for the domain of embedded systems?

 Yes, if the system is designed in an aspect-aware manner

Obliviousness? No! Quantification? Yes!

slide-26
SLIDE 26

wosch@cs.fau.de - USENIX 2009

28 28

CiAO: Aspect-Aware OS Design

 Idea of aspect awareness:

Provide unambiguous and statically evaluable join points.

 Unambiguity:

Important system state transitions can be captured by a pointcut expression.

 Static evaluation:

Avoid necessity for dynamic pointcut functions, which bear an overhead.

slide-27
SLIDE 27

wosch@cs.fau.de - USENIX 2009

31 31

CiAO: Aspect-Aware OS Design

 Result:

Sparse base system designed with classes, most functionality provided by (optional) aspects

 Three main aspect purposes:

  • Extension aspects: add features
  • Policy aspects: glue components together
  • Upcall aspects: bind behavior to lower-level events

Loose coupling Visible transitions Minimal extensions

slide-28
SLIDE 28

wosch@cs.fau.de - USENIX 2009

32 32

Extension Aspects

 Example: task scheduling

// base implementation struct Task { Pri pri_; State state_; … }; class Sched { Tasklist ready_; Task::Id running_; public: void activate(Task::Id t); void reschedule(); … };

slide-29
SLIDE 29

wosch@cs.fau.de - USENIX 2009

33 33

Extension Aspects

 Example: task scheduling extended (resource control)

// base implementation struct Task { Pri pri_; State state_; … }; class Sched { Tasklist ready_; Task::Id running_; public: void activate(Task::Id t); void reschedule(); … }; aspect ResourceSupport { advice “Task” : slice struct { ResourceMask occupied_; Pri originalPri_; }; advice “Sched” : slice class { public: void getRes(Res::Id r) { // lock mutex } void relRes(Res::Id r) { // unlock mutex } }; };

ResourceSupport.ah

slide-30
SLIDE 30

wosch@cs.fau.de - USENIX 2009

34 34

Policy Aspects

 Example: specification of preemption points

aspect FullPreemption { // points where another task may get a higher prio pointcut pcPreemptionPoints = “% Sched::activate(…)” || “% Sched::setEvent(…)” || “% Sched::relRes(…)”; advice execution(pcPreemptionPoints()) : after() { tjp->that()->reschedule(); } };

Preemption.ah

slide-31
SLIDE 31

wosch@cs.fau.de - USENIX 2009

35 35

Upcall Aspects

 Example: binding of an interrupt handler

aspect TimerBinding { advice execution(“% irq::Timer::handler(…)”) : after() { // handle IRQ } };

TimerBinding.ah

slide-32
SLIDE 32

wosch@cs.fau.de - USENIX 2009

36 36

Talk Outline

 Cross-cutting in Configurable System Software  Aspect-Oriented Programming (AOP) to the Rescue?  CiAO: Aspect-Aware OS Design  Evaluation: Suitability for Embedded Systems

slide-33
SLIDE 33

wosch@cs.fau.de - USENIX 2009

37 37

Evaluation

 Suitability of AOP for configurable systems

  • Increased modularization?
  • Scalability?

 Suitability of AOP for resource-constrained systems

  • Resource efficiency?
  • Scalability?
slide-34
SLIDE 34

wosch@cs.fau.de - USENIX 2009

38 38

Evaluation

 Suitability of AOP for configurable systems

  • Increased modularization?
  • Scalability?

 Suitability of AOP for resource-constrained systems

  • Resource efficiency?
  • Scalability?
slide-35
SLIDE 35

wosch@cs.fau.de - USENIX 2009

39 39

Evaluation

 Suitability of AOP for configurable systems

  • Increased modularization?
  • Scalability?

 Suitability of AOP for resource-constrained systems

  • Resource efficiency?
  • Scalability?
slide-36
SLIDE 36

wosch@cs.fau.de - USENIX 2009

40 40

Evaluation

 Suitability of AOP for configurable systems

  • Increased modularization?
  • Scalability?

 Suitability of AOP for resource-constrained systems

  • Resource efficiency?
  • Scalability?
slide-37
SLIDE 37

wosch@cs.fau.de - USENIX 2009

41 41

Evaluation

 Suitability of AOP for configurable systems

  • Increased modularization? Yes!
  • Scalability? Good!

 Suitability of AOP for resource-constrained systems

  • Resource efficiency? Good!
  • Scalability? Good!
slide-38
SLIDE 38

wosch@cs.fau.de - USENIX 2009

42 42

Evaluation: Issues

 Aspects for low-level code:

  • Transformations can break fragile join points (e.g., context switch)
  • Explicit join points with empty functions

 Aspect–aspect interdependencies:

  • Order advice, if several aspects affect same join point

 Join-point traceability:

  • Visualization of join-point deltas between revisions
  • Further tool support needed (acdt.aspectc.org)

 Granularity:

  • Advices apply to procedures (i.e. calls), not statements
slide-39
SLIDE 39

wosch@cs.fau.de - USENIX 2009

43 43

Summary

 AOP is very well suited for the implementation of highly

configurable system software, avoiding #ifdef hell

 With aspect-awareness design principles in mind, the

increased modularization comes at no costs

 CiAO is the first aspect-oriented operating system

slide-40
SLIDE 40

wosch@cs.fau.de - USENIX 2009

44 44

Summary

 AOP is very well suited for the implementation of highly

configurable system software, avoiding #ifdef hell

 With aspect-awareness design principles in mind, the

increased modularization comes at no costs

 CiAO is the first aspect-oriented operating system

Thanks for your attention!