Changes between Version 16 and Version 17 of WikiStart
- Timestamp:
- 04/07/09 14:49:28 (8 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WikiStart
v16 v17 22 22 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. 23 23 24 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. 24 [[Image(htdocs:pics/overview.gif, alt="Overview",align=center,25%)]] 25 25 26 [[Image(htdocs:pics/overview.gif, alt="Overview",align=center,40%)]] 27 28 29 26 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: [wiki:NewC4Syntax] 30 27 31 28 = Publications =
