FOSD Presentation

212 views
175 views

Published on

Presentation of our paper at FOSD 2012

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
212
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

FOSD Presentation

  1. 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.dk1/28 IV International Workshop on Feature Oriented Software Development (FOSD’12)
  2. 2. In evolving variant-rich software. . .2/28
  3. 3. In evolving variant-rich software. . . • New features are added3/28
  4. 4. In evolving variant-rich software. . . • New features are added • Features are removed3/28
  5. 5. In evolving variant-rich software. . . • New features are added • Features are removed 1. feature is no longer supported: complete removal3/28
  6. 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. 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. 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: • merge3/28
  9. 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 • split3/28
  10. 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 • rename3/28
  11. 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. 12. Example (from Linux)4/28
  13. 13. ... Ralink Drivers ... RT2860 RT3090 ...4/28
  14. 14. ... Ralink Drivers ... RT2860 RT3090 ...4/28
  15. 15. ... Ralink Drivers ... RT2860 ...4/28
  16. 16. ... Ralink Drivers ... RT2860 ... Complete removal?4/28
  17. 17. Existing evolution studies tend to focus on the variability model alone5/28
  18. 18. That doesn’t tell the whole story. . .6/28
  19. 19. Ralink Drivers ... RT2860 RT3090 ...7/28
  20. 20. Ralink Drivers Configuration space ... RT2860 RT3090 ...7/28
  21. 21. Ralink Drivers ... RT2860 RT3090 ... Compilation space7/28
  22. 22. Ralink Drivers ... RT2860 RT3090 ... Implementation space7/28
  23. 23. Spaces are connected. . .7/28
  24. 24. Ralink Drivers ... RT2860 RT3090 ...7/28
  25. 25. Ralink Drivers ... RT2860 RT3090 ...7/28
  26. 26. Ralink Drivers ... RT2860 RT3090 ...7/28
  27. 27. Ralink Drivers ... RT2860 RT3090 ...7/28
  28. 28. With the three spaces in mind, the real picture of . . .8/28
  29. 29. ... Ralink Drivers ... RT2860 RT3090 ... is8/28
  30. 30. Ralink Drivers ... RT2860 RT3090 ...8/28
  31. 31. Ralink Drivers ... RT2860 RT3090 ... copy copy copy8/28
  32. 32. Ralink Drivers ... RT2860 RT3090 ... copy copy copy RT3090 is merged into RT28608/28
  33. 33. We want to know. . .9/28
  34. 34. How do the three spaces evolve together in real world variant rich software?10/28
  35. 35. How do the three spaces evolve together in real world variant rich software? Focus: features that disappear from the configuration space10/28
  36. 36. Two goals Understand the evolution of the three spaces in a real-word variant rich software11/28
  37. 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. 38. Our subject of analysis12/28
  39. 39. Qualities of Linux as a subject of study • Mature: over 20 years since its first release13/28
  40. 40. Qualities of Linux as a subject of study • Mature: over 20 years since its first release • Complex: over 6,000 features13/28
  41. 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. 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 development13/28
  43. 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. 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: Kconfig13/28
  45. 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: Makefile13/28
  46. 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 code13/28
  47. 47. Variability evolution patterns from Linux14/28
  48. 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. 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 logs16/28
  50. 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. 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 discussion18/28
  52. 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 discussion18/28
  53. 53. Optional feature to implicit mandatory19/28
  54. 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. 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. 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. 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. 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 List20/28
  59. 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 X21/28
  60. 60. Our patterns have direct implications. . .22/28
  61. 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. 62. Conclusions24/28
  63. 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. 64. Future work26/28
  65. 65. Future work • Collect patterns not restricted to removals • Measure frequency • Study other systems27/28
  66. 66. Thanks for listening!28/28

×