Presentation of our paper at FOSD 2012

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