This document discusses a study of variability evolution patterns in the Linux kernel. The researchers analyzed how features are removed from the configuration space over time in Linux across three pairs of stable releases. They identified four patterns through manual analysis of 140 removed features, including patterns where an optional feature becomes implicit/mandatory or where features are merged through module aliasing. The patterns show that features can disappear from the configuration space while still existing in other spaces, which previous evolution studies focusing only on variability models did not capture.

1. Towards a Catalog of Variability Evolution Patterns – The
Linux Kernel Case
Leonardo Passos Krzysztof Czarnecki Andrzej Wasowski
University of Waterloo University of Waterloo IT University of Copenhagen
lpassos@gsd.uwaterloo.ca kczarnec@gsd.uwaterloo.ca wasowski@itu.dk
1/28 IV International Workshop on Feature Oriented Software Development (FOSD’12)

2. In evolving variant-rich
software. . .
2/28

3. In evolving variant-rich software. . .
• New features are added
3/28

4. In evolving variant-rich software. . .
• New features are added
• Features are removed
3/28

5. In evolving variant-rich software. . .
• New features are added
• Features are removed
1. feature is no longer supported: complete removal
3/28

6. In evolving variant-rich software. . .
• New features are added
• Features are removed
1. feature is no longer supported: complete removal
2. feature continues to be supported, but its abstraction is no longer
present (disappears from the variability model).
3/28

7. In evolving variant-rich software. . .
• New features are added
• Features are removed
1. feature is no longer supported: complete removal
2. feature continues to be supported, but its abstraction is no longer
present (disappears from the variability model).
Examples:
3/28

8. In evolving variant-rich software. . .
• New features are added
• Features are removed
1. feature is no longer supported: complete removal
2. feature continues to be supported, but its abstraction is no longer
present (disappears from the variability model).
Examples:
• merge
3/28

9. In evolving variant-rich software. . .
• New features are added
• Features are removed
1. feature is no longer supported: complete removal
2. feature continues to be supported, but its abstraction is no longer
present (disappears from the variability model).
Examples:
• merge
• split
3/28

10. In evolving variant-rich software. . .
• New features are added
• Features are removed
1. feature is no longer supported: complete removal
2. feature continues to be supported, but its abstraction is no longer
present (disappears from the variability model).
Examples:
• merge
• split
• rename
3/28

11. In evolving variant-rich software. . .
• New features are added
• Features are removed
1. feature is no longer supported: complete removal
2. feature continues to be supported, but its abstraction is no longer
present (disappears from the variability model).
Examples:
• merge
• split
• rename
• Constraints are changed, etc.
3/28

12. Example
(from Linux)
4/28

13. ...
Ralink Drivers
... RT2860 RT3090 ...
4/28

14. ...
Ralink Drivers
... RT2860 RT3090 ...
4/28

15. ...
Ralink Drivers
... RT2860 ...
4/28

16. ...
Ralink Drivers
... RT2860 ...
Complete removal?
4/28

17. Existing evolution studies tend
to focus on the variability model
alone
5/28

18. That doesn’t tell the whole
story. . .
6/28

19. Ralink Drivers
... RT2860 RT3090 ...
7/28

20. Ralink Drivers
Configuration space
... RT2860 RT3090 ...
7/28

21. Ralink Drivers
... RT2860 RT3090 ...
Compilation space
7/28

22. Ralink Drivers
... RT2860 RT3090 ...
Implementation
space
7/28

23. Spaces are connected. . .
7/28

24. Ralink Drivers
... RT2860 RT3090 ...
7/28

25. Ralink Drivers
... RT2860 RT3090 ...
7/28

26. Ralink Drivers
... RT2860 RT3090 ...
7/28

27. Ralink Drivers
... RT2860 RT3090 ...
7/28

28. With the three spaces in mind,
the real picture of . . .
8/28

29. ...
Ralink Drivers
... RT2860 RT3090 ...
is
8/28

30. Ralink Drivers
... RT2860 RT3090 ...
8/28

31. Ralink Drivers
... RT2860 RT3090 ...
copy
copy
copy
8/28

32. Ralink Drivers
... RT2860 RT3090 ...
copy
copy
copy
RT3090 is merged into RT2860
8/28

33. We want to know. . .
9/28

34. How do the three spaces evolve
together in real world variant
rich software?
10/28

35. How do the three spaces evolve
together in real world variant
rich software?
Focus: features that disappear from the
configuration space
10/28

36. Two goals
Understand the evolution of the three spaces in a
real-word variant rich software
11/28

37. Two goals
Understand the evolution of the three spaces in a
real-word variant rich software
Document our understanding in the form of evolution
patterns (preliminary).
11/28

38. Our subject of analysis
12/28

39. Qualities of Linux as a subject of study
• Mature: over 20 years since its first release
13/28

40. Qualities of Linux as a subject of study
• Mature: over 20 years since its first release
• Complex: over 6,000 features
13/28

41. Qualities of Linux as a subject of study
• Mature: over 20 years since its first release
• Complex: over 6,000 features
• Changes are kept in a publicly available SCM Repository (git)
13/28

42. Qualities of Linux as a subject of study
• Mature: over 20 years since its first release
• Complex: over 6,000 features
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
13/28

43. Qualities of Linux as a subject of study
• Mature: over 20 years since its first release
• Complex: over 6,000 features
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Contains multiple spaces:
13/28

44. Qualities of Linux as a subject of study
• Mature: over 20 years since its first release
• Complex: over 6,000 features
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Contains multiple spaces:
◦ configuration space: Kconfig
13/28

45. Qualities of Linux as a subject of study
• Mature: over 20 years since its first release
• Complex: over 6,000 features
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Contains multiple spaces:
◦ configuration space: Kconfig
◦ compilation space: Makefile
13/28

46. Qualities of Linux as a subject of study
• Mature: over 20 years since its first release
• Complex: over 6,000 features
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Contains multiple spaces:
◦ configuration space: Kconfig
◦ compilation space: Makefile
◦ implementation space: C code
13/28

47. Variability evolution patterns
from Linux
14/28

48. Data collection & Analysis
• Data collection is limited to three pairs of stable kernel releases in
x86 64
• For each pair, we considered only the features that disappeared
from the configuration space
• Manual analysis of 140 removals from a total of 220 (63%)
15/28

49. Infrastructure
• Extraction and reuse of Kconfig parsing infrastructure from Linux
itself
◦ allow us to compute disappearing features among each release kernel
• Conversion of Linux patches from git into a relational database
◦ allow us to quickly identify which commit erases a feature from the
configuration space
• git log + gitk, grep: visualize and search logs
16/28

50. Extracting patterns is hard!
Difficulties in analyzing patches when collecting patterns:
• unrelated changes (noise)
• technical comments (too much jargon)
• extensive set of changes
• everything is recorded in the SCM as addition/removal of lines
(too low level)
17/28

51. Four identified patterns
• Optional feature to implicit mandatory
• Computed attributed feature to code
• Merge features by module aliasing
• Optional feature to kernel parameter
Template: structure, instance and discussion
18/28

52. Four identified patterns
• Optional feature to implicit mandatory
• Computed attributed feature to code
• Merge features by module aliasing
• Optional feature to kernel parameter
Template: structure, instance and discussion
18/28

53. Optional feature to implicit
mandatory
19/28

54. Structure & Instance
X X
... ... ... ...
Y CTC CTC[XY]
if Y, if Y, if X,
compile Y.c into Y.o compile Y.c into Y.o
compile X.c into X.c compile X.c into X.c
#ifdef X
Y.c #ifdef Y
...
Y.c #ifdef Y
...
#endif #endif
(Before) (After)
20/28

55. Structure & Instance
X X
... ... ... ...
Y CTC CTC[XY]
if Y, if Y, if X,
compile Y.c into Y.o compile Y.c into Y.o
compile X.c into X.c compile X.c into X.c
#ifdef X
Y.c #ifdef Y
...
Y.c #ifdef Y
...
#endif #endif
(Before) (After)
20/28

56. Structure & Instance
X X
... ... ... ...
Y CTC CTC[XY]
if Y, if Y, if X,
compile Y.c into Y.o compile Y.c into Y.o
compile X.c into X.c compile X.c into X.c
#ifdef X
Y.c #ifdef Y
...
Y.c #ifdef Y
...
#endif #endif
(Before) (After)
20/28

57. Structure & Instance
X X
... ... ... ...
Y CTC CTC[XY]
if Y, if Y, if X,
compile Y.c into Y.o compile Y.c into Y.o
compile X.c into X.c compile X.c into X.c
#ifdef X
Y.c #ifdef Y
...
Y.c #ifdef Y
...
#endif #endif
(Before) (After)
20/28

58. Structure & Instance
X X
... ... ... ...
Y CTC CTC[XY]
if Y, if Y, if X,
compile Y.c into Y.o compile Y.c into Y.o
compile X.c into X.c compile X.c into X.c
#ifdef X
Y.c #ifdef Y
...
Y.c #ifdef Y
...
#endif #endif
(Before) (After)
Instance: X = OCFS, Y= OCFS Access Control List
20/28

59. Discussion
Pattern should be used when:
• users should not be given the freedom to configure Y
◦ e.g.: they may inadvertly forget to select it, as in Access Control List
(Y)
• Y is a critical feature that makes sense to exist in the software,
given the presence of its parent X
21/28

60. Our patterns have direct
implications. . .
22/28

61. Direct implications
• Existing evolution studies (She et al. at Vamos’10, Lotufo et. al.
at SPLC’10) focus on the variability model alone: our patterns
show that features can be erased from the configuration space,
while still present in the implementation space
• Our patterns capture situations not covered by the existing SPL
evolution theory (Borba et al. at ITAC’10)
◦ compatibility of product is not guaranteed (evolution is not safe)
23/28

62. Conclusions
24/28

63. Conclusions
• Evolution must focus on all spaces
• We presented 4 patterns extracted from Linux
• Our patterns explain the evolution of features removed from the
configuration space
• They show evolution steps not captured in previous studies (both
theoretical and empirical).
25/28

64. Future work
26/28

65. Future work
• Collect patterns not restricted to removals
• Measure frequency
• Study other systems
27/28

66. Thanks for listening!
28/28