Reinhard Tartler

A quantitative analysis of aspects in the eCos kernel

Nearly ten years after its first presentation and five years after its first application to operating systems, the suitability of Aspect-Oriented Programming (AOP) for the development of operating system kernels is still highly in dispute. While the AOP advocacy emphasizes the benefits of AOP towards better configurability and maintainability of system software, most kernel developers express a sound skepticism regarding the thereby induced runtime and memory costs: Operating system kernels have to be lean and efficient.We have analyzed the runtime and memory costs of aspects in general, on the level of μ-benchmarks, and by refactoring and extending the eCos operating system kernel using AspectC++, an AOP extension to the C++ language. Our results show that most AOP features do not induce a intrinsic overhead and that the actual overhead induced by AspectC++ is very low. We have also analyzed a test case with significant aspect-related costs. This example shows how the structure of the underlying kernel can have a negative impact on aspect implementations and how these costs can be avoided by an aspect-aware design.Based on this analysis, our conclusion is that AOP is suitable for the development of operating system kernels and other kinds of highly efficient infrastructure software.

Feature consistency in compile-time-configurable system software: facing the linux 10,000 feature problem

Much system software can be configured at compile time to tailor it with respect to a broad range of supported hardware architectures and application domains. A good example is the Linux kernel, which provides more than 10,000 configurable features, growing rapidly. From the maintenance point of view, compile-time configurability imposes big challenges. The configuration model (the selectable features and their constraints as presented to the user) and the configurability that is actually implemented in the code have to be kept in sync, which, if performed manually, is a tedious and error-prone task. In the case of Linux, this has led to numerous defects in the source code, many of which are actual bugs. We suggest an approach to automatically check for configurability-related implementation defects in large-scale configurable system software. The configurability is extracted from its various implementation sources and examined for inconsistencies, which manifest in seemingly conditional code that is in fact unconditional. We evaluate our approach with the latest version of Linux, for which our tool detects 1,776 configurability defects, which manifest as dead/superfluous source code and bugs. Our findings have led to numerous source-code improvements and bug fixes in Linux: 123 patches (49 merged) fix 364 defects, 147 of which have been confirmed by the corresponding Linux developers and 20 as fixing a new bug.

A robust approach for variability extraction from the Linux build system

With more than 11,000 optional and alternative features, the Linux kernel is a highly configurable piece of software. Linux is generally perceived as a textbook example for preprocessor-based product derivation, but more than 65 percent of all features are actually handled by the build system. Hence, variability-aware static analysis tools have to take the build system into account. However, extracting variability information from the build system is difficult due to the declarative and turing-complete make language. Existing approaches based on text processing do not cover this challenges and tend to be tailored to a specific Linux version and architecture. This renders them practically unusable as a basis for variability-aware tool support -- Linux is a moving target! We describe a robust approach for extracting implementation variability from the Linux build system. Instead of extracting the variability information by a text-based analysis of all build scripts, our approach exploits the build system itself to produce this information. As our results show, our approach is robust and works for all versions and architectures from the (git-)history of Linux.

Variability mechanisms in software ecosystems

Abstract Context Software ecosystems are increasingly popular for their economic, strategic, and technical advantages. Application platforms such as Android or iOS allow users to highly customize a system by selecting desired functionality from a large variety of assets. This customization is achieved using variability mechanisms. Objective Variability mechanisms are well-researched in the context of software product lines. Although software ecosystems are often seen as conceptual successors, the technology that sustains their success and growth is much less understood. Our objective is to improve empirical understanding of variability mechanisms used in successful software ecosystems. Method We analyze five ecosystems, ranging from the Linux kernel through Eclipse to Android. A qualitative analysis identifies and characterizes variability mechanisms together with their organizational context. This analysis leads to a conceptual framework that unifies ecosystem-specific aspects using a common terminology. A quantitative analysis investigates scales, growth rates, and—most importantly—dependency structures of the ecosystems. Results In all the studied ecosystems, we identify rich dependency languages and variability descriptions that declare many direct and indirect dependencies. Indirect dependencies to abstract capabilities, as opposed to concrete variability units, are used predominantly in fast-growing ecosystems. We also find that variability models—while providing system-wide abstractions over code—work best in centralized variability management and are, thus, absent in ecosystems with large free markets. These latter ecosystems tend to emphasize maintaining capabilities and common vocabularies, dynamic discovery, and binding with strong encapsulation of contributions, together with uniform distribution channels. Conclusion The use of specialized mechanisms in software ecosystems with large free markets, as opposed to software product lines, calls for recognition of a new discipline—variability encouragement.

Understanding linux feature distribution

Managing variability is hard. This applies both to feature modeling itself as well as the maintenance of the corresponding feature implementations which poses additional challenges. Especially in embedded systems and system software that are developed using the tools CPP, GCC and MAKE, feature realizations happen on different levels of abstractions, concepts and implementation languages. This particularly applies to Linux, which exposes over 11000 features on over two dozen different architectures. While features are modeled centrally with the Kconfig tool, feature-code is realized in various source-files and managed by the Kbuild build-system. In this article, we identify and relate levels of variability on which feature-code is implemented. The quantification of variability on the different levels in Linux disproves two common beliefs about the amount of implemented variability.

Revealing and repairing configuration inconsistencies in large-scale system software

System software typically offers a large amount of compile-time options and variability. A good example is the Linux kernel, which provides more than 10,000 configurable features, growing rapidly. This allows users to tailor it with respect to a broad range of supported hardware architectures and application domains. From the maintenance point of view, compile-time configurability poses big challenges. The configuration model (the selectable features and their constraints as presented to the user) and the configurability that is actually implemented in the code have to be kept in sync, which, if performed manually, is a tedious and error-prone task. In the case of Linux, this has led to numerous defects in the source code, many of which are actual bugs. In order to ensure consistency between the variability expressed in the code and the configuration models, we propose an approach that extracts variability from both into propositional logic. This reveals inconsistencies between variability as expressed by the C Preprocessor (CPP) and an explicit variability model, which manifest themselves in seemingly conditional code that is in fact unconditional. We evaluate our approach with the Linux, for which our tool detects 1,766 configurability defects, which turned out as dead/superfluous source code and bugs. Our findings have led to numerous source-code improvements and bug fixes in Linux: 123 patches (49 merged) fix 364 defects, 147 of which have been confirmed by the corresponding Linux developers and 20 as fixing a previously unknown bug.

Linux variability anomalies: What causes them and how do they get fixed?

The Linux kernel is one of the largest configurable open source software systems implementing static variability. In Linux, variability is scattered over three different artifacts: source code files, Kconfig files, and Makefiles. Previous work detected inconsistencies between these artifacts that led to anomalies in the intended variability of Linux. We call these variability anomalies. However, there has been no work done to analyze how these variability anomalies are introduced in the first place, and how they get fixed. In this work, we provide an analysis of the causes and fixes of variability anomalies in Linux. We first perform an exploratory case study that uses an existing set of patches which solve variability anomalies to identify patterns for their causes. The observations we make from this dataset allow us to develop four research questions which we then answer in a confirmatory case study on the scope of the whole Linux kernel. We show that variability anomalies exist for several releases in the kernel before they get fixed, and that contrary to our initial suspicion, typos in feature names do not commonly cause these anomalies. Our results show that variability anomalies are often introduced through incomplete patches that change Kconfig definitions without properly propagating these changes to the rest of the system. Anomalies are then commonly fixed through changes to the code rather than to Kconfig files.

Challenges in operating-systems reengineering for many cores

General purpose operating systems such as Linux are reasonably suited for managing massively parallel computing platforms made from many-core processors. However, due to limitations in organization and architecture of the system software, these sorts of operating systems are fairly unsuited for parallel execution in order to better perform on behalf of the (massively) parallel processes needed for running one or more application programs. Regarding many-core support, their functional properties are satisfactorily, however, their nonfunctional properties leave a lot to be desired. The paper touches on some of the problems discovered in reengineering critical sections of operating systems. It aims at making aware of difficulties, rather than providing solutions, in adapting system software to parallel processing.