Constructing Component-Based Extension Interfaces in Legacy Systems Code Gilles Muller École des Mines de Nantes Julia Lawall DIKU, University of Copenhagen Jean-Marc Menaud, Mario Sudholt École des Mines de Nantes

Page 2 The OS designer/researcher problem u How to implement my new wonderful idea? u Design a full OS from scratch? –Too much work –Limited support and compatibility (drivers, libraries)  Extend a legacy OS

Page 3 Extending a Legacy OS How to add event generation? Linux kernel with scheduling events Run- Time System User- defined scheduling policy Implementation of the Bossa process scheduling framework

Page 4 Problems in extending a legacy OS with new functions u How to plug new functions in the existing code –Interfaces may not exist u How to be sure that the extension is correctly done –One modification may have to be done in many places –The legacy OS may evolve –What about extending multiples OSes? u How to be sure that the whole system is consistent –Many extensions may cohabit

Page 5 Our Approach u Automate the extension process –Document modifications so that the process can be repeated and verified u Turn the system into a set of components –Legacy OS, extensions u Define new component interfaces –Identify points of interaction between the legacy OS and the extension –Define rewrite rules that construct support for interactions –Use an existing component framework (KNIT[OSDI’00], Think [Usenix’02])

Page 6 Defining new interfaces Legacy OS call_extension() Extension kmalloc() kfree() è Low-level code rewrite is needed

Page 7 Rewrite rule features u Insert new definitions –Wrappers for legacy functions, data structures u Insert code within existing definitions –Calls to the extension entry points –Data structure fields used by the extension u Remove code within existing definitions è We need to reason about the execution path

Page 8 1- Inserting code within existing definitions u update_times keeps track of time in Linux u Bossa entry point rts_clocktick marks the passage of time Add a call to rts_clocktick after the call to update_times In timer_bh: update_times(args) → After rts_clocktick()

Page Removing code within existing definitions u Linux function schedule –preempts the current process –elects a new one –performs the context switch u Bossa entry point rts_schedule –preempts the current process –elects a new one Replace part of schedule with a call to rts_schedule

Page 10 Specifying a region of code u rts_schedule replaces code that is both –after the taking of the runqueue lock –before the releasing of the runqueue lock u Temporal logic used to describe code regions –AF: On all forward paths, there exists … –AFΔ: On all backward paths, there exists … In schedule: ALL(AFΔ spin_lock_irq(&runqueue_lock) & AF spin_unlock_irq(&runqueue_lock)) → … rts_schedule(caller) …

Page Error checking u Safety criteria: –A rule never applies –Multiple rules apply at a single code point u Error rules: –Illegal patterns, partial matches In schedule: (AFΔ spin_lock_irq(&runqueue_lock) & (¬AF spin_unlock_irq(&runqueue_lock) | ¬AFΔ spin_unlock_irq(&runqueue_lock))) → Error(“runqueue lock taken but not released: ambiguous rts_schedule”)

Page 12 Component view of Bossa Kernel_to_RTS RTS_to_kernel Kernel_entry_points Kernel_to_bossa RTS_to_policy Policy_to_RTS Modified Linux Kernel RTS Policy

Page 13 Component Generation u Knit elements: –Bundletypes: list related objects bundletype RTS_to_kernel = { rts_clocktick, rts_schedule, … } –Units: use bundletypes to describe module imports and exports unit Kernel = { imports [ rts_to_kernel : RTS_to_kernel ]; exports [ kernel_to_Bossa : Kernel_to_Bossa, … ]; … }

Page 14 Knit interfaces extended with rewrite rules u Bundletypes include rewrite rules to apply when the object is imported or exported bundletype RTS_to_kernel = { rts_clocktick { import: In timer_bh: update_times(args) → After rts_clocktick() }, … }

Page 15 Experiments u Bossa –23 rewrites rules –20 exported functions –13 imported functions –Applied over the Linux 2.4 kernel (100MB) u SQUID –Add support for specific prefetching policies –4 rewrites rules –25 exported functions –4 imported functions

Page 16 Future work u Improvement of error detection u Jaluna/Chorus re-engineering to support virtual machine monitor u Extend Linux/Bossa with energy support u Target the Fractal/Think component framework u Turn Linux into components u Release our prototype

Page 17 Conclusion A replacement for “patch” u AOP inspired approach to OS evolution u Approach specifically targeted to system needs –Side result of Bossa u Promising initial experiments u Step towards the integration of components and AOP