Patch (1) Considered Harmful

Linux is increasingly used to power everything from embedded devices to supercomputers. Developers of such systems often start with a mainline kernel from kernel.org and then apply patches for their application domain. Many of these patches represent crosscutting concerns in that they do not fit within a single program module and are scattered throughout the kernel sources--easily affecting over a hundred files. It requires nontrivial effort to maintain such a crosscutting patch, even across minor kernel upgrades due to the variability of the kernel proper. Moreover, it is a significant challenge to ensure the kernel's correctness when integrating multiple crosscutting concerns. To make matters worse, developers use simple code merging tools that directly manipulate source file lines instead of relying on a lexical, grammatical, or semantic level of abstraction. The result is that patch maintenance is extremely time consuming and error prone. In this paper, we propose a new tool, called c4, designed to help manipulate patches at the level of their abstract syntax and semantics. We believe our approach will simplify the management of OS variations and thereby improve OS evolution.

[1]  Jean-Marc Menaud,et al.  Constructing component-based extension interfaces in legacy systems code , 2004, EW 11.

[2]  Thomas Ledoux,et al.  Aspect-Oriented Software Development , 2003 .

[3]  Martin C. Rinard,et al.  A classification system and analysis for aspect-oriented programs , 2004, SIGSOFT '04/FSE-12.

[4]  Gregor Kiczales,et al.  Brittle systems will break - not bend: can aspect-oriented programming help? , 2002, EW 10.

[5]  Julia L. Lawall,et al.  On the automatic evolution of an OS kernel using temporal logic and AOP , 2003, 18th IEEE International Conference on Automated Software Engineering, 2003. Proceedings..

[6]  David Walker,et al.  A theory of aspects , 2003, ICFP '03.

[7]  Radha Jagadeesan,et al.  A Calculus of Untyped Aspect-Oriented Programs , 2003, ECOOP.

[8]  Gary T. Leavens,et al.  Observers and Assistants: A Proposal for Modular Aspect-Oriented Reasoning , 2002 .

[9]  Olivier Motelet,et al.  A Formal Definition of Crosscuts , 2001, Reflection.

[10]  David Walker,et al.  Harmless advice , 2006, POPL '06.

[11]  Gregor Kiczales,et al.  A semantics for advice and dynamic join points in aspect-oriented programming , 2001, TOPL.

[12]  Gilles Muller,et al.  Tarantula{:} Killing Driver Bugs Before They Hatch , 2004 .

[13]  Gregor Kiczales,et al.  Using aspectC to improve the modularity of path-specific customization in operating system code , 2001, ESEC/FSE-9.

[14]  Rémi Douence,et al.  Composition, reuse and interaction analysis of stateful aspects , 2004, AOSD '04.

[15]  Brian N. Bershad,et al.  Improving the reliability of commodity operating systems , 2003, SOSP '03.

[16]  Robert Grimm Systems Need Languages Need Systems ! , 2005 .

[17]  KiczalesGregor,et al.  Using aspectC to improve the modularity of path-specific customization in operating system code , 2001 .

[18]  Robert Grimm rgrimm Practical Packrat Parsing , 2004 .

[19]  Robert J. Walker,et al.  Evaluating Emerging Software Development Technologies: Lessons Learned from Assessing Aspect-Oriented Programming , 1999, IEEE Trans. Software Eng..

[20]  Lujo Bauer,et al.  Types and Effects for Non-interfering Program Monitors , 2002, ISSS.

[21]  Hidehiko Masuhara,et al.  Compilation Semantics of Aspect-Oriented Programs , 2002 .

[22]  Gregor Kiczales,et al.  Back to the future: a retroactive study of aspect evolution in operating system code , 2003, AOSD '03.

[23]  Daniel Mahrenholz,et al.  An Aspect-Oriented Implementation of Interrupt Synchronization in the PURE Operating System Family∗ , 2002 .