Constructing%20Component-Based%20Extension%20Interfaces%20in%20Legacy%20Systems%20Code

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
  (KNITOSDI00, Think Usenix02)

6
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_loc
k) AF spin_unlock_irq(runqueue_lo
ck)) ? 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