1 / 17

Constructing Component-Based Extension Interfaces in Legacy Systems Code

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.

avel
Download Presentation

Constructing Component-Based Extension Interfaces in Legacy Systems Code

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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?

  4. 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

  5. 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])

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

  7. 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

  8. 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()

  9. 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

  10. 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) …

  11. 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”)

  12. 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

  13. 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, … ]; … }

  14. 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() } , … }

  15. 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

  16. 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

  17. 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

More Related