Managing Variability in Systems: Oh What a Tangled OS We Weave
چکیده
This position paper outlines challenges associated with managing OS variants, key ways in which AOP could help, and criteria for adoption that we believe AOP must meet. 1. INTRODUCTION Major variants to a mainline Linux kernel are typically represented in terms of high level frameworks and low level patches. Frameworks are typically vetted several times in the operating systems community before becoming mainlined into the kernel. Patches that quietly sprinkle the necessary hooks for the framework throughout the existing system receive less attention. Developers trying to manage variants manifested as patches are given no support when trying to understand the code. Frameworks that have recently been mainlined include Linux Security Modules (LSM) [10], Advanced Linux Sound Architecture (ALSA) [1], and Video4Linux [13]. There are many others possibly soon to be mainlined, such as Class-Based Kernel Resource Management (CKRM) [5] and Linux Trace Toolkit (LTT) [11]. These are just a few of the many frameworks that resort to rudimentary patching schemes. Though aspect-oriented programming (AOP) [9, 4] is poised to help, criteria for its adoption must ensure smooth integration with current approaches and tools within a systems context. To this end, we examine a concrete example, describe how AOP could help, establish criteria of adoption, and finally describe an experiment we plan to explore. Class-based Kernel Resource Management (CKRM) [5] project is developing new kernel mechanisms to provide differentiated service to shared system resources. These resources include CPU, memory, I/O and network bandwidth. At a low level, changes associated with this variant have been organized into several patches, as outlined in Table 1. The table shows that some patches are self-contained, involving no changes to the existing code, whereas others change collections of files. In more detail, these patches dictate where " hunks " of code are applied, at specific line numbers or relative offsets within specific files, throughout the system. For example, this portion of a CKRM patch (00-core.ckrm-E12.patch): @@-619,6 +623,9 @@ } else return-EPERM; + + ckrm_cb_gid(); + return 0; } instruments an existing file with a call to the ckrm_cb_gib() function. Line numbers are represented as relative offsets indicated by @@ @@. Precisely which function is instrumented is not clear looking at the patch. But upon closer inspection some patterns are clear – all calls to ckrm_cb_gid()/uid() (6 in total) directly precede return statements, and ckrm_cb_exit()/newtask() are at the beginning and end of functions in exit/fork.c. Leveraging these clues …