Overview
This page describes the initial (partial) release of the CrossCutting C Compiler(C4) toolkit. This toolkit is intended to bring Aspect-Oriented Software Development (AOSD) techniques to the C language. The toolkit consists of three source-to-source transformation tools: C4 weaver, C4 unweaver, and a C4-to-C compiler of C code extended with AOSD feature.
The C4-to-C compiler, based on the xtc compiler framework, has been used to introduce aspects into linux-2.6.12. Moreover, we have tested that the kernel properly compiles and runs. The weaver and unweaver tools are still under development --- mostly hampered by the nastiness of dealing with CPP. The figure below illustrates how the toolkit is intended to fit into a programmer's development process.
The weaver/unweaver tools are intended to eliminate the need for programmers to learn anything out of the ordinary for defining aspect advice for C code. Advice is defined inline with simple syntatic sugar that any C programmer can learn within seconds --- we call this the woven C4 view of an aspect. This woven C4 code is an extension on top of the C language that lets developers define an aspect with before, after, and around advice. The advice can instrument on function, struct/union, and global. After defining an aspect in this way a programmer can use the unweaver tool to extract such inline code from the C code and place it in a separate C4 aspect file using a grammar based upon AspectC. Concrete examples of this are presented below. Conversely, the weaver will read such C4 aspect files and source-to-source rewrite the C code to which the advice applies.
The C4-to-C compiler translates the woven C4 code into conventional C code. The result can then be compiled by an optimizing backend compiler, such as gcc, to produce a binary. For the C4 syntax please refer to C4Syntax. If you want to test out C4, head to C4Usage to see how to run C4 on woven-c source files.
New Development
C4 is a domain specific version of C that lets developers both easily and safely manage program extensions (particularly those representing a crosscutting concern) leveraging AOSD techniques. The goal of our work is to improve the extensibility approach for the Linux kernel. Towards this goal we focused on maintaining tool compatibility, understandability, and overall performance.
One of the main challenge when introducing a new approach is how to promote its adoption by the targeted developers. Developers can be reluctant to modify their current development workflow by introducing extra-steps which may require new tools. Specifically, developers such as those working on the Linux kernel would likely reject anything that was perceived as a new programming paradigm / language (even C++), is difficult to debug, imposed undue runtime overhead, or did not follow the well-established model of inline development, extraction, distribution, and reintegration of extensions.
To ease the adoption of our AOSD inspired extensions model it is important that it minimizes the need for new tools such as compilers, make, etc. or otherwise modifies the development workflow. The current workflow for developing and distributing extensions historically relies on the patch and diff tools.
As a brief overview, adding extensions creates major variants to a mainline code base. The current best practice is to implement such an extension by directly modifying the mainline code base. Developers start with mainline and implement their extension by changing the source code to meet the performance or functionality requirements of their target application domain. For instance, Linux-VServer that provides virtualization for Linux is distributed as a patch set that implements kernel level isolation. Upon completing the development of an extension, the developers extract the extension with tools based upon diff to create a patch set. They can then share the resulting patch set with others, who in turn integrate the extension into their version of the mainline code base using tools based upon patch.
The development workflow remains the same with our approach with inline development, extraction, optionally distribution and finally integration of an extension in the mainline code. Mapping our approach to the workflow shown in the figure above, the extension is still implemented by directly modifying the mainline program to arrive at the extended program. An optional analyzer can be run to verify various properties regarding the C4 extension. Next, the extraction process involves unweaving C4-defined extensions from the C source code of the extended program resulting in a stand-alone extension based on a patch-derived notation called B4. Specifically an enhanced diff-like tool that understands the C4 before/after aspect semantics is used to perform the extraction and produce the B4 files. At this stage the extension can optionally be distributed using conventional means (e.g., email, web, etc.). The integration process involves using the patch tool set to apply the B4 extension that supports an enhanced patch notation. Specifically the enhanced notation is only used to integrate C4 after advice, but for C4 introductions and before advice our solution seamlessly works together with existing patch set tools. More elements can be found here: NewC4Syntax
Publications
On Reconciling Patches and Aspects.
By Laurent Burgy, Marc E. Fiuczynski, Marco Yuen and Robert Grimm. In Proceedings of the 8th Workshop on Aspects, Components, and Patterns for Infrastructure Software, 6 pages, Charlottesville, Virginia, March 2009.
On the feasibility of an AOSD approach to Linux kernel extensions.
By Alison Reynolds, Marc E. Fiuczynski, and Robert Grimm. In Proceedings of the 7th Workshop on Aspects, Components, and Patterns for Infrastructure Software, 6 pages, Brussels, Belgiumm, March 2008.
Making extensibility of system software practical with the C4 toolkit.
By Marco Yuen, Marc Fiuczysnki, Robert Grimm, Yvonne Coady, and David Walker. In 2006 AOSD Workshop on Software Engineering Properties of Languages and Aspect Technologies, 6 pages, Bonn, Germany, March 2006.
HEY... You got your Paradigm in my Operating System!
By Chris Matthews, Owen Stampflee, Yvonne Coady, Jonathan Appavoo, Marc E. Fiuczynski, and Robert Grimm. In Proceedings of the 2nd ECOOP Workshop on Programming Languages and Operating Systems, Glasgow, UK, July 2005.
By Marc E. Fiuczynski, Robert Grimm, Yvonne Coady, and David Walker. In Proceedings of the 10th Workshop on Hot Topics in Operating Systems, Santa Fe, New Mexico, June 2005.
Managing Variability in Systems: Oh What a Tangled OS We Weave.
By Stuart Bray, Marco Yuen, Yvonne Coady, and Marc E. Fiuczynski. In MVCDC Workshop, OOPSLA, 2004.
C4 Repository
C4 repository can be accessed at http://c4.cs.princeton.edu/svn/c4
