An Empirical Study of Configuration Mismatches in Linux

Abstract

Ideally the variability of a product line is represented completely and correctly by its variability model. However, in practice additional variability is often represented on the level of the build system or in the code. Such a situation may lead to inconsistencies, where the actually realized variability does not fully correspond to the one described by the variability model. In this paper we focus on con guration mismatches, i.e., cases where the e ective variability di ers from the variability as it is represented by the variability model. While previous research has already shown that these situations still exist even today in well-analyzed product lines like Linux, so far it was unclear under what circumstances such issues occur in reality. In particular, it is open what types of con guration mismatches occur and how severe they are. Here, our contribution is to close this gap by presenting a detailed manual analysis of 80 con guration mismatches in the Linux 4.4.1 kernel and assess their criticality. We identify various categories of con guration issues and show that about two-thirds of the con guration mismatches may actually lead to kernel miscon gurations. CCS CONCEPTS•Software and its engineering →Software veri cation; Software product lines; •Social and professional topics →Software maintenance;

Product-line assurance cases from contract-based design

“…8. The described issues are referred to as configuration mismatches [25], and in general they represent a mismatch between the product line design, here represented as a CBD model, and the product line specification, which is here represented as a variability model.…”

KernelHaven -- An Open Infrastructure for Product Line Analysis

“…Hence, it does not need a variability model extractor as well as the respective For this purpose, a user simply excludes the corresponding parameters from KernelHaven's configuration file. Further, the ConfigurationMismatches analysis builds upon the same configuration as it uses the results of the feature effect analysis to check whether the implemented (effective) variability matches the variability model [9]. This concatenation of processing plug-ins results in processing or analysis pipelines, which we describe in detail in [14].…”

Automated analysis of feature models: Quo vadis?

“…Product configuration and derivation [35,37,42,46,47,49,50,53,55,56,57,58,59,60,65,66,68,72,74,75,76,77,80,82,83,89,93,95,98,99,100,103,105,106,107,108,109,110,112,114,116,118,119,120,123,125,126,128,133,134,135,136,…”

“…Evaluation Research [28,29,32,33,36,37,38,39,40,41,42,43,45,46,47,48,49,50,52,54,55,56,59,67,68,69,70,71,77,82,83,85,86,87,88,89,90,92,94,96,97,98,100,103,104,107,109,110,111,112,113,114,…”