The extension of our FOSD paper

1. Coevolution of Variability Models and Related Artifacts
A Case Study from the Linux Kernel
Leonardo Passos1 Jianmei Guo1 Leopoldo Teixeira2
Krzysztof Czarnecki1 Andrzej Wąsowski3 Paulo Borba2
1University of Waterloo 2Federal University of Pernambuco 3IT University
17th International Software Product Line Conference
1/32

2. A concrete change from the Linux
kernel
2/32

3. Ralink Drivers
RT2860
...
... ...RT3090
2/32

4. Ralink Drivers
RT2860
...
... ...RT3090
2/32

5. Ralink Drivers
RT2860
...
... ...
2/32

6. Ralink Drivers
RT2860
...
... ...
Does it mean that RT3090 is no longer supported?
2/32

7. Existing evolution studies tend to focus
on the variability model alone
3/32

8. That doesn’t tell the whole story. . .
4/32

9. Ralink Drivers
RT2860... ...RT3090
5/32

10. Ralink Drivers
RT2860... ...RT3090
Variability model
(Kconfig)
5/32

11. Ralink Drivers
RT2860... ...RT3090
Mapping
(Makefiles)
5/32

12. Ralink Drivers
RT2860... ...RT3090
Implementation
(.h and .c files)
5/32

13. Different artifacts, in different spaces,
are connected. . .
5/32

14. Ralink Drivers
RT2860... ...RT3090
5/32

15. Ralink Drivers
RT2860... ...RT3090
5/32

16. Ralink Drivers
RT2860... ...RT3090
5/32

17. Ralink Drivers
RT2860... ...RT3090
Implementation file
(.c or .h)
5/32

18. Ralink Drivers
RT2860... ...RT3090
macro directive
(e.g.:, #ifdef RT2860)
5/32

19. With the three spaces in mind, the real
picture of . . .
6/32

20. Ralink Drivers
RT2860
...
... ...RT3090
is
6/32

21. Ralink Drivers
RT2860... ...RT3090
6/32

22. Ralink Drivers
RT2860... ...RT3090
copy
copy
copy
6/32

23. Ralink Drivers
RT2860... ...RT3090
copy
copy
copy
Therefore, RT3090 is merged into RT2860
6/32

24. But, what can be said about the few
studies that take coevolution into
account?
7/32

25. Studies that consider coevolution
• Borba et al., GPCE 2011
8/32

26. Studies that consider coevolution
• Borba et al., GPCE 2011
◦ Small case study: Mobile Media and TaRGeT ≈ 40 features
8/32

27. Studies that consider coevolution
• Borba et al., GPCE 2011
◦ Small case study: Mobile Media and TaRGeT ≈ 40 features
◦ Unlikely to capture the complexity typically found in large systems
8/32

28. Studies that consider coevolution
• Borba et al., GPCE 2011
◦ Small case study: Mobile Media and TaRGeT ≈ 40 features
◦ Unlikely to capture the complexity typically found in large systems
◦ Case study restricted to refinement changes (guarantee product
compatibility)
8/32

29. Studies that consider coevolution
• Borba et al., GPCE 2011
◦ Small case study: Mobile Media and TaRGeT ≈ 40 features
◦ Unlikely to capture the complexity typically found in large systems
◦ Case study restricted to refinement changes (guarantee product
compatibility)
• Seidl et al., SPLC 2012
8/32

30. Studies that consider coevolution
• Borba et al., GPCE 2011
◦ Small case study: Mobile Media and TaRGeT ≈ 40 features
◦ Unlikely to capture the complexity typically found in large systems
◦ Case study restricted to refinement changes (guarantee product
compatibility)
• Seidl et al., SPLC 2012
◦ Validated over a small and fictitious example
8/32

31. We need practical case studies of
variability coevolution in large complex
variability rich software
9/32

32. Better understanding
tools mirroring coevolution as it
happens in practice
10/32

33. Our work
11/32

34. A catalog of 13 coevolution patterns
from a large and complex system
(Linux kernel)
Provides a concrete set of coevolution
operations performed in practice12/32

35. A set of findings from the analyses of
the catalog and its instances
Presented as take home lessons
13/32

36. Linux as a subject of study
• Mature: over 20 years of development
14/32

37. Linux as a subject of study
• Mature: over 20 years of development
• Complex (in v3.3), with over
14/32

38. Linux as a subject of study
• Mature: over 20 years of development
• Complex (in v3.3), with over
◦ 12, 000 features
14/32

39. Linux as a subject of study
• Mature: over 20 years of development
• Complex (in v3.3), with over
◦ 12, 000 features
◦ 80, 000 compile-time variation points
14/32

40. Linux as a subject of study
• Mature: over 20 years of development
• Complex (in v3.3), with over
◦ 12, 000 features
◦ 80, 000 compile-time variation points
◦ 16, 000 Makefiles
14/32

41. Linux as a subject of study
• Mature: over 20 years of development
• Complex (in v3.3), with over
◦ 12, 000 features
◦ 80, 000 compile-time variation points
◦ 16, 000 Makefiles
◦ 30, 000 header and C files
14/32

42. Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
14/32

43. Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
14/32

44. Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Variability spreads different artifacts (spaces):
14/32

45. Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Variability spreads different artifacts (spaces):
◦ Variability model: Kconfig
14/32

46. Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Variability spreads different artifacts (spaces):
◦ Variability model: Kconfig
◦ Mapping: Makefile
14/32

47. Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Variability spreads different artifacts (spaces):
◦ Variability model: Kconfig
◦ Mapping: Makefile
◦ Implementation: annotated C code (CPP directives: #ifdefs)
14/32

48. Catalog of evolution patterns
15/32

49. Methodology for extracting patterns
2.6.26
2.6.27
3.1
3.2
. . .
added feature names
removed feature names
time
feature name f
primary commit commit window (cw)
1. Sample Collection
Added feature names: 206 (5%)
Sample of removed feature names: 101 (10%)
2. Commit retrieval
(adds/removes f from
the variability model)
complements the primary commit
(changes of f are in other spaces)
3. Analysis & Clustering 4. Pattern extraction
almost 4 years of development
(Additions sample)
(Removals sample)
16/32

50. Catalog of evolution patterns
(additions sample)
17/32

51. Pattern catalog (additions sample)
Rename
(Sample size = 206, Population size = 4,112)
Additions sample
18/32

52. Pattern catalog (additions sample)
Creation of
feature from
existing
code
(Sample size = 206, Population size = 4,112)
Additions sample
18/32

53. Pattern catalog (additions sample)
Creation of
feature from
new
elements
(Sample size = 206, Population size = 4,112)
Additions sample
18/32

54. Pattern catalog (additions sample)
Not patterns
(Sample size = 206, Population size = 4,112)
Additions sample
18/32

55. Pattern catalog (additions sample)
Two most frequent patterns:
Add Visible Optional Modular Feature
(AVOMF)
Add Visible
Optional
Non-Modular
Feature
(AVONMF)
18/32

56. Add Visible Optional
Modular Feature
(Example)
19/32

57. Add Visible Optional Modular Feature
Example: CAPTURE_DAVINCI_DM646_EVM
CAPTURE_DAVINCI_DM646_EVM
VIDEO_DEV
... ...
...
CTC' = CTC + (CAPTURE_DAVINCI_DM646_EVM requires MACH_EVM)
M' = M + new compilation rule:
if CAPTURE_DAVINCI_DM646_EVM is set
compile vpfi_capture.c
I'= I + vpfi_capture.c
CTC: set of cross tree constraints
M: Mapping
I: Implementation
(Before state) (After state)
[visible]
VIDEO_DEV
... ...
...
20/32

58. Add Visible Optional
Non-Modular Feature
(Example)
21/32

59. Add Visible Optional Non-Modular Feature
Example: SQUASHFS_4K_DEVBLK_SIZE
SQUASHFS_4K_DEVBLK_SIZE
SQUASHFS
... ...
...
CTC' = CTC + constraints of SQUASHFS_4K_DEVBLK_SIZE
I'= I + <
#ifdef SQUASHFS_4K_DEVBLK_SIZE
#define SQUASHFS_DEVBLK_SIZE 4096
#else
#define SQUASHFS_DEVBLK_SIZE 1024
#endif
>
CTC: set of cross tree constraints
M: Mapping
I: Implementation
(Before state) (After state)
[visible]
SQUASHFS
... ...
...
M: Mapping
22/32

60. Findings
(additions sample)
23/32

61. Findings (additions sample)
• AVOMF:
◦ Most features in Linux are modular
◦ Modular features in AVOMF cause little scattering outside their
module
• AVONMF:
◦ ifdefs of non-modular features are coarse-grained, appearing mostly in
the global (e.g., a conditional data structure) or function level (e.g.,
conditional statements)
24/32

62. Take home lesson #1
(practical)
Disciplined use of annotation-based techniques such as
#ifdefs do not hinder evolution (hypothesis)
25/32

63. Catalog of evolution patterns
(removals sample)
26/32

64. Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Remove Visible
Optional Modular
Feature
(RVOMF)
27/32

65. Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Remove Visible
Optional
Non-Modular
Feature
(RVONMF)
27/32

66. Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Inverse
removals of
patterns in the
additions sample
27/32

67. Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Merges: feature name is removed from the variability model,
but feature continues to be supported elsewhere
Merge Visible
Optional
Feature
into
Sibling
(MVOFS)
Merge of
RT3090
into
RT2860
27/32

68. Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Rename
27/32

69. Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Not
patterns
27/32

70. Findings (removals sample)
• Merges:
◦ Evolution requires a holistic view
◦ Merges can only be identified by retrieving coevolving artifacts
• Complete feature removal (e.g., RVOMF = AVOMF−1)
◦ Affect the set of supported products; thus not a refinement
◦ Refinement changes are too restrictive in practice, as complete feature
removals are often frequent (43% of all removals)
28/32

71. Take home lesson #2
(methodological)
Effective understanding of variability evolution requires
looking at the coevolution of different artifacts
29/32

72. Take home lesson #3
(requirements for tool implementors)
The set of patterns provide concrete operations on how
artifacts coevolve
Catalog provides evidence on which operations are
important (e.g., we did not find split operations)
30/32

73. Conclusion
• We sumarized a catalog of 13 patterns that include coevolution of:
◦ Variability model
◦ Mapping
◦ Implementation
• Subject of analysis: a large and complex software system – the
Linux kernel
• Presented three take home lessons (full list of findings in the paper)
31/32

74. Thanks for listening!
32/32