On the Automatic Evolution of an OS Kernel using Temporal Logic and AOP

1. On the Automatic Evolution of an OS Kernel using Temporal Logic and AOP Julia L. Lawall DIKU, University of Copenhagen Joint work with: Rickard A. Åberg, Mario Südholt, Gilles Muller Obasco Group, Ecole des Mines de Nantes/INRIA Anne-Françoise Le Meur Compose Group, INRIA/LABRI, ENSEIRB

2. Overview • Goal: Automating software evolution • Context: • Support for the Bossa scheduling framework • Our approach: • Aspect-oriented programming (AOP) • Temporal Logic

3. Bossa scheduling framework • Goal: • Allow application programmers to implement kernel-level process schedulers • Functionality of a process scheduler: • Decide when to elect a new process • Decide what process to elect • Information needed from the kernel: • Times when electing a new process is allowed • Changes in process states

4. Standard kernel with added events Standardxx kernel with added events User- defined scheduling policy events Bossa architecture Who adds all the events?

5. Distribution of events 77 files require modification (Linux 2.4.18)

6. Linux kernel code // request process state change set_current_state(TASK_INTERRUPTIBLE); add_wait_queue(&md->lynx->mem_dma_intr_wait, &wait); run_sub_pcl(md->lynx, md->lynx->dcmem_pcl, 2, CHANNEL_LOCALBUS); // electing a new process is allowed schedule( ); Problem: Bossa process election function depends on process state.

7. Bossa-Linux kernel code // change process state set_current_state(TASK_INTERRUPTIBLE); add_wait_queue(&md->lynx->mem_dma_intr_wait, &wait); run_sub_pcl(md->lynx, md->lynx->dcmem_pcl, 2, CHANNEL_LOCALBUS); // electing a new process is allowed schedule_interruptible( ); Choice of event depends on the requested process state. Problem: Bossa process election function depends on process state.

8. Observations • Events occur within function bodies. • Choice of event is context-sensitive • Depends on information local to the function, but not local to the event-notification site • Information and rewriting site may be separated by if, while, etc.

9. Requirements • Automated approach • Manual modification is tedious and error-prone • Portability • Treat multiple kernel versions

10. Solution:AOP & Temporal logic • Aspect-oriented programming • Scheduling behavior crosscuts the kernel • AOP localizes event-notification strategy separate from the kernel code • reduces specification size (one entry per concept) • allows modification of multiple kernels • Typically applied to function call/return sites • Temporal logic • A logic describing sequences of events • Our use: describe control-flow patterns

11. Temporal logic (CTL) • Propositional logic: • p, true, false,  ,  ,  • One step in the future • One path: EX • All paths: AX • Multiple steps in the future • One path: E(U) • All paths: A(U) • Backwards variants • AX, A(U), etc. p,q q p p EXp

12. Temporal logic (CTL) • Propositional logic: • p, true, false,  ,  ,  • One step in the future • One path: EX • All paths: AX • Multiple steps in the future • One path: E(U) • All paths: A(U) • Backwards variants • AX, A(U), etc. p,q q p p A(p U q)

13. Temporal logic (CTL) • Propositional logic: • p, true, false,  ,  ,  • One step in the future • One path: EX • All paths: AX • Multiple steps in the future • One path: E(U) • All paths: A(U) • Backwards variants • AX, A(U), etc. p,q q p p A(p U q)

14. Temporal logic (CTL) • Propositional logic: • p, true, false,  ,  ,  • One step in the future • One path: EX • All paths: AX • Multiple steps in the future • One path: E(U) • All paths: A(U) • Backwards variants • AX, A(U), etc. p,q q p p A(p U q)

15. Example rule Replace try_to_wake_up by bossa_unblock_process. n:(call(try_to_wake_up))  Rewrite(n,bossa_unblock_process(args))

16. Example rule (simplified) If the state is TASK_INTERRUPTIBLE, replace schedule() by schedule_interruptible(). n:(call(schedule)) Rewrite(n,schedule_interruptible(args)) If n ├ AX(A(changeOfState() U setState(TASK_INTERRUPTIBLE)))

17. Processing Linux kernel code // change process state set_current_state(TASK_INTERRUPTIBLE); add_wait_queue(&md->lynx->mem_dma_intr_wait, &wait); run_sub_pcl(md->lynx, md->lynx->dcmem_pcl, 2, CHANNEL_LOCALBUS); // electing a new process is allowed schedule( ); set_current_state (TASK_INTERRUPTIBLE) add_wait_queue • n:(call(schedule))  • Rewrite(n,schedule_interruptible(args)) • If AX(A(changeOfState() U • setState(TASK_INTERRUPTIBLE))) run_sub_pcl schedule

18. Assessment • 38 rules (9 use temporal logic). • Approach validated on • Linux 2.4.18 • Linux 2.4.21 • patched Linux 2.4.18 • Same performance as a manually reengineered kernel. • Errors found in the hand-modified version.

19. Conclusions and future work • Problem: • Kernel evolution for Bossa requires crosscutting modifications • Modifications occur in function bodies and depend on context information • Solution: AOP & Temporal Logic • Future targets: • Linux 2.6, Windows, other OS services http://www.emn.fr/x-info/bossa