170 likes | 304 Vues
This paper explores the challenges and solutions in extending legacy operating systems using a component-based approach. It addresses common issues such as compatibility, support for new features, and integration of extensions within existing code. By automating the extension process and defining new interfaces, we propose a framework for transforming legacy systems into modular components. Using the Bossa process scheduling framework, we demonstrate methods for risk management, error detection, and component generation. The results indicate a promising direction for system evolution and integration.
E N D
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
The OS designer/researcher problem • How to implement my new wonderful idea? • Design a full OS from scratch? • Too much work • Limited support and compatibility (drivers, libraries) • Extend a legacy OS
Extending a Legacy OS Implementation of the Bossa process scheduling framework Run-Time System Linux kernel with scheduling events User- defined scheduling policy events How to add event generation?
Problems in extending a legacy OS with new functions • How to plug new functions in the existing code • Interfaces may not exist • 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? • How to be sure that the whole system is consistent • Many extensions may cohabit
Our Approach • Automate the extension process • Document modifications so that the process can be repeated and verified • Turn the system into a set of components • Legacy OS, extensions • 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])
Extension kmalloc() call_extension() kfree() Defining new interfaces Legacy OS • Low-level code rewrite is needed
Rewrite rule features • Insert new definitions • Wrappers for legacy functions, data structures • Insert code within existing definitions • Calls to the extension entry points • Data structure fields used by the extension • Remove code within existing definitions • We need to reason about the execution path
1- Inserting code within existing definitions • update_times keeps track of time in Linux • 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()
2 - Removing code within existing definitions • Linux function schedule • preempts the current process • elects a new one • performs the context switch • Bossa entry point rts_schedule • preempts the current process • elects a new one Replace part of schedule with a call to rts_schedule
Specifying a region of code • rts_schedule replaces code that is both • after the taking of the runqueue lock • before the releasing of the runqueue lock • 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) …
3 - Error checking • Safety criteria: • A rule never applies • Multiple rules apply at a single code point • 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”)
Component view of Bossa Kernel_to_bossa RTS_to_policy Kernel_to_RTS Modified Linux Kernel RTS Policy Policy_to_RTS RTS_to_kernel Kernel_entry_points
Component Generation • 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, … ]; … }
Knit interfaces extended with rewrite rules • 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() } , … }
Experiments • Bossa • 23 rewrites rules • 20 exported functions • 13 imported functions • Applied over the Linux 2.4 kernel (100MB) • SQUID • Add support for specific prefetching policies • 4 rewrites rules • 25 exported functions • 4 imported functions
Future work • Improvement of error detection • Jaluna/Chorus re-engineering to support virtual machine monitor • Extend Linux/Bossa with energy support • Target the Fractal/Think component framework • Turn Linux into components • Release our prototype
Conclusion A replacement for “patch” • AOP inspired approach to OS evolution • Approach specifically targeted to system needs • Side result of Bossa • Promising initial experiments • Step towards the integration of components and AOP