Your SlideShare is downloading. ×
FOSD Presentation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

FOSD Presentation

123

Published on

Presentation of our paper at FOSD 2012

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
123
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. In evolving variant-rich software. . .2/28
  • 3. In evolving variant-rich software. . . • New features are added3/28
  • 4. In evolving variant-rich software. . . • New features are added • Features are removed3/28
  • 5. In evolving variant-rich software. . . • New features are added • Features are removed 1. feature is no longer supported: complete removal3/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: • merge3/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 • split3/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 • rename3/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 alone5/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 space7/28
  • 22. Ralink Drivers ... RT2860 RT3090 ... Implementation space7/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 ... is8/28
  • 30. Ralink Drivers ... RT2860 RT3090 ...8/28
  • 31. Ralink Drivers ... RT2860 RT3090 ... copy copy copy8/28
  • 32. Ralink Drivers ... RT2860 RT3090 ... copy copy copy RT3090 is merged into RT28608/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 space10/28
  • 36. Two goals Understand the evolution of the three spaces in a real-word variant rich software11/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 analysis12/28
  • 39. Qualities of Linux as a subject of study • Mature: over 20 years since its first release13/28
  • 40. Qualities of Linux as a subject of study • Mature: over 20 years since its first release • Complex: over 6,000 features13/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 development13/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: Kconfig13/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: Makefile13/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 code13/28
  • 47. Variability evolution patterns from Linux14/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 logs16/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 discussion18/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 discussion18/28
  • 53. Optional feature to implicit mandatory19/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 List20/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 X21/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. Conclusions24/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 work26/28
  • 65. Future work • Collect patterns not restricted to removals • Measure frequency • Study other systems27/28
  • 66. Thanks for listening!28/28

×