Scenario Conclusions - Feature Model Synthesis

Different scenarios impose different requirements on a feature model synthesis work- flow. For example, scenarios involving domain analysis may require a natural language analysis tool to extract variability from requirements, and a synthesis algorithm that constructs a feature diagram that is weaker, or complete, with respect to the input configurations. Synthesizing a feature model from source code on the other hand, would require a variability-aware static analysis tool, and a sound synthesis capable of handling the dependencies that were not identified by the analysis. Other considera- tions for synthesis algorithms include the size of the input and whether a probabilistic

model is needed. The scenarios and requirements that we derived could be used to encourage research on new synthesis techniques and promote new applications and improvements to existing synthesis techniques.

Real World Variability Models

Variability modeling and supporting tools have grown in popularity over the years. How- ever, realistic benchmarks for evaluating variability modeling tools have generally been inaccessible with the growing interest from both tool vendors and researchers[SRC09].

While some variability models are already available, e.g., SPLOT model repository1, very few of them originate from realistic processes; most are small examples from research publications, or outcomes of student run case studies. Given the lack of realistic large-scale models, many tool builders have resorted to using randomly generated models[WSB+08,TBRC+08,MWC09,BSRC10].

This chapter describes our research on realistic variability models extracted from open-source projects. We focused our study on the variability model of the Linux kernel and its variability modeling language called Kconfig. Kconfig was developed specifically for supporting the variability modeling and configuration of Linux. The Kconfig language share so many similarities with feature modeling that a Kconfig model can be interpreted as a feature model [SSSPS07]. Our study includes a total of 12

variability models specified with the Kconfig language and compare their properties against a set of 267 feature models gathered from the SPLOT model repository.

Chapter Organization In Section 4.1, we introduce the Kconfig language and its concepts. We present the abstract syntax for the Kconfig language in Section4.2and describe its mapping to feature modeling concepts in Section4.3. In Section4.4, we compare models properties of the variability models of the Linux kernel and 11 other projects with those of the models gathered from the SPLOT model repository. The formal semantics of Kconfig are available in AppendixAfor those interested.

Publications Our first publication involving the Kconfig language was a study of the Linux variability model[SLB+10]. In [BSL+10b], we compared variability modeling

concepts, semantics, usage and tools in Kconfig, CDL and feature modeling using Linux and eCos operating system kernels as the study subjects. We expanded on this study in[BSL+12], to include 12 Kconfig models, variants of the eCos model, and 267 SPLOT

models. The Kconfig semantics were published as a technical note[SB10].

External Contributions The qualitative study in Section 4.4.6 was performed by Rafael Lotufo and published in [SLB+10]. The study of the Kconfig language and

the Linux variability model has material from[BSL+10b] and [BSL+12]. The Kcon-

fig semantics [SB10] in Appendix A were developed collaboratively with Thorsten Berger.

4.1 Kconfig Language

The Linux kernel originally used the Configuration Menu Language (CML) as its configuration language until v2.5.45 in 2002, where it was replaced with Kconfig (referred to as LinuxKernelConf at the time)[Wik12]. The Kconfig language is supported by

several configurators. The ‘menuconfig’ tool is terminal interface for configuring a Kconfig model, the ‘nconfig’ tool that replaces the menuconfig tool using the ncurses2 framework, and the ‘xconfig’ is a graphical configurator written using the Qt framework. The structure of a Kconfig model closely resembles a feature model in that configuration options are nested to form a hierarchy. We describe the features of the Kconfig language next.

Feature Kinds There are four types of nodes in a Kconfig tree: menu,menuconfig,

config,choice. Menuconfigsandconfigsdeclare symbols that appear in a configuration.

Choicesandmenusare grouping constructs that do not appear in a configuration. A Kconfig configuration is simply a list of key-value pairs, where symbols can be undefined if the corresponding config is unselected. We discuss the four feature kinds using the Kconfig snippet in Figure4.1:

1 menuconfig MISC_FILESYSTEMS 2 bool "Miscellaneous filesystems" 3

5 if MISC_FILESYSTEMS 6

7 config JFFS2_FS

8 tristate "Journalling Flash File System" if MTD 9 select CRC32 if MTD

10 11

12 config JFFS2_FS_DEBUG

13 int "JFFS2 Debug level (0=quiet, 2=noisy)" 14 depends on JFFS2_FS 15 default 0 16 range 0 2 17 --- help --- 18 Debug verbosity of ... 19 20 21 config JFFS2_FS_WRITEBUFFER 22 bool 23 depends on JFFS2_FS 24 default HAS_IOMEM 25 26 27 config JFFS2_COMPRESS

28 bool "Advanced compression options for JFFS2" 29 depends on JFFS2_FS

30 31

32 config JFFS2_ZLIB

33 bool "Compress w/zlib..." if JFFS2_COMPRESS 34 depends on JFFS2_FS 35 select ZLIB_INFLATE 36 default y 37 38 39 choice

40 prompt "Default compression" if JFFS2_COMPRESS 41 default JFFS2_CMODE_PRIORITY

42 depends on JFFS2_FS 43

44 config JFFS2_CMODE_NONE 45 bool "no compression" 46

47 config JFFS2_CMODE_PRIORITY 48 bool "priority"

50 config JFFS2_CMODE_SIZE 51 bool "size (EXPERIMENTAL)" 52 endchoice

53 endif

configs Configs declare a unique symbol used to represent individual configuration options. Configs are the basic symbols in a Kconfig model and can hold a Boolean, tristate (i.e., three-valued), integer, hexadecimal, or string value.

JFFS2_FS at Line 7 in Figure 4.1 is a tristate config in our snippet. Nesting between configs are shown as a tree-view with indentation in the graphical configurator. See Figure4.2for the graphical rendering of the Kconfig snippet.

menus Menus are used purely for lexically grouping features in the configurator. Menus do not declare a symbol, and thus, do not appear in a configuration.

menuconfigs Menuconfigs have the same appearance as menus in the graphical configurator, however, menuconfigs also declare a symbol and can hold a value just like configs. MISC_FILESYSTEMS is a menuconfig and all features within the following if condition (Line5) are children ofMISC_FILESYSTEMS.

choices Choices are similar to feature groups in feature modeling where they are used to impose grouping constraints on its children, called choice members. Choices can be of Boolean or tristate type. A Boolean choice allows at most one choice member to be selected, and a tristate choice allows more more than one choice menmber to be selected. By default, a choice requires that at least one child be selected, however, choices can be made optional with the optional keyword. Choice members are declared as configs. Default compression in Line 39 is an example of a choice grouping.

Feature Representation In Kconfig, a configuration assigns a single value to each feature. A special empty value is used to denote the absence of a feature. There are five types that restrict the valid values of configuration options in Kconfig: bool,tristate,

int,hex, andstring.

Thebooltype has two possible values,

y

and

n

, internally represented by the numbers 2 and 0; 0 denotes feature absence, while 2 means that the feature’s implementation is compiled statically into the kernel. Thetristatetype is an extension ofboolwith an additional

m

value, represented internally by 1. The

m

value denotes that the feature should be compiled as a dynamically loadable module. For example,JFFS2_ZLIBhas type bool andJFFS2_FSis tristate. Kconfig supports two integer types: int(decimal) andhex(hexadecimal). Both types also allow an empty value, which is used to encode the absence of the numeric feature. The typestringis ambiguous when handling the empty string: a string feature with the empty value can be seen as a present feature with

Figure 4.2: xconfig rendering of the Kconfig snippet in Figure4.1

that value or an absent feature; the two cases are indistinguishable when examining a Kconfig configuration.

Hierarchy Configuration options in Kconfig are organized into a hierarchy similar to feature modeling. In feature modeling, the hierarchy imposes a configuration constraint where a child feature implies the presence of its parent feature. In Kconfig, the parent- child implication is not enforced—a child feature can be selected when its parent is not. Furthermore, a symbol can appear in multiple places in the hierarchy, but are ultimately the same feature and share the same values. These properties leads to a separation between a Kconfig model’s syntactic hierarchy (as it appears in the configurator) and the configuration semantics—constraints imposed on the set of configurations.

Each node in Kconfig has an associated prompt condition that controls its visibility. The visibility condition specifies when a feature is visible in the configurator and can be changed by a user. A visibility condition that evaluates to

m

y

causes a feature to be visible in the configurator. Furthermore, the visibility conditions of features is used to determine the syntactic hierarchy of a Kconfig model. In terms of the configuration semantics, the visibility condition imposes an upper bound on the allowed values of the feature.

Operator Kconfig Evaluation

n

mod

m

yes

y

and

A && B

min(A,B)

A || B

max(A,B)

not

!A

2 - A

equals

A = B

if (toString(A)= toString(B)) 2 else 0

Figure 4.3: Evaluating operators and literals in the three-valued logic of Kconfig The hierarchy rendered by the xconfig configurator for the Kconfig snippet in Figure4.1 is shown in Figure4.2. TheMISC_FILESYSTEMSfeature is at the top of the hierarchy because of the enclosing if condition over all other features. Features that follow

JFFS2_FSdepend onJFFS2_FSmaking it their parent. TheJFFS2_ZLIBfeature has a specific prompt condition, i.e., visibility condition, that causes it to be nested under

JFFS2_COMPRESS; however,JFFS2_ZLIBdoes not depend onJFFS2_COMPRESS

according to its configuration semantics. In other words,JFFS2_ZLIBcan be selected even ifJFFS2_COMPRESSis deselected, thus, violating the parent-child constraint seen in feature modeling.

Constraints and Expression Language Kconfig uses a three-valued logic for ex- pressing and evaluating expressions. At its core, Kconfig has three literals:

n

(no),

m

(module),

y

(yes). There are five operators: and, or, not, equals, andnot equals. Figure4.3 shows the rules for evaluating these operators. The equals operator has a unique property in that it uses the string value of its arguments. For example, the literal

y

and the string “y” would be equal in Kconfig.

A symbol can declare the following constraints: prompts, defaults, select clauses, or valid ranges for intorhexsymbols. Each constraint may have a condition to describe when the constraint is active. The prompt condition controls when a symbol is visible and changeable by the user in the configurator. As a result, the prompt condition determines the visibility condition of the config.

A default condition is used to set a default value for a symbol. Under most circumstances, a default enforces a soft constraint—a suggestion for the user that can be overridden and does not enforce a constraint on the set of valid configurations. However, a default

can interact with prompt conditions creating a hard configuration constraint. This situation occurs if a symbol’s prompt condition evaluates to false; the value of the symbol cannot be changed, and the symbol takes the value of the first active default. A select clause enforces the selection of another symbol if the current symbol is also selected. Select clauses stem from the imperative nature of the Kconfig configurators. Thedepends onclause is syntactic sugar for applying a condition across all constraints in a symbol’s declaration. For example, in line14, thedepends on statement adds

JFFS2_FSas a dependency to the prompt, default and range.

In document Feature Model Synthesis (Page 60-68)