Linux kernel test automation with kdevops
328 | Thu 31 Jul 4:30 p.m.–5:15 p.m.
Presented by
-
Luis is a Principal Engineer at Samsung focusing the development and adoption of future Samsung NVMe storage & memory solutions on open ecosystems. Luis has been working on the Linux kernel for over 20 years, and his fields of interest has changed over time, from Wireless, Bluetooth, Ethernet, to virtualization and lately with storage and memory technologies. He has also helped spearhead different new automation open source projects such as the Linux kernel backports project and as of late the kdevops project.
Abstract
We have a slew of ways to test the Linux kernel: selftests, kunit, and then we have a slew of subsystem specific tests. Intel 0-day has also done a fantastic job at helping find bugs. So has syzkaller. Some subsystems like filesystems and memory management have really complex test frameworks though and have falling behind in automation. Is it possible to automate testing of complex subsystems? Should we? And what are the implications if we're successful?
To provide perspective, it takes roughly 10 years to stabilize a new Linux filesystem. But can we do better? The kdevops project was started with the goal of first of addressing automation of testing of complex subsystems such as filesystems to help reduce the amount of time it takes to stabilize new filesystems or new filesystem features. The project aimed at supporting local virtualization, bare metal, and all cloud provider support. Seven years later since the project got started, with the help of a lot of community collaboration the project is now integral part not only of testing pipelines but also development workflows. The kdevops project now enables continuous integration for different subsystems starting with:
* Linux modules
* Linux radix tree
* Linux filesystems: xfs, btrfs, ext4
* Linux network filesystems: NFS
* Linux selftests
A dashboard of results is now also updated automatically based on automatic tests: https://kdevops.org
What have we learned from all this effort so far? And what lies ahead for the roadmap? If you want to contribute and help how do you do that?
We have a slew of ways to test the Linux kernel: selftests, kunit, and then we have a slew of subsystem specific tests. Intel 0-day has also done a fantastic job at helping find bugs. So has syzkaller. Some subsystems like filesystems and memory management have really complex test frameworks though and have falling behind in automation. Is it possible to automate testing of complex subsystems? Should we? And what are the implications if we're successful? To provide perspective, it takes roughly 10 years to stabilize a new Linux filesystem. But can we do better? The kdevops project was started with the goal of first of addressing automation of testing of complex subsystems such as filesystems to help reduce the amount of time it takes to stabilize new filesystems or new filesystem features. The project aimed at supporting local virtualization, bare metal, and all cloud provider support. Seven years later since the project got started, with the help of a lot of community collaboration the project is now integral part not only of testing pipelines but also development workflows. The kdevops project now enables continuous integration for different subsystems starting with: * Linux modules * Linux radix tree * Linux filesystems: xfs, btrfs, ext4 * Linux network filesystems: NFS * Linux selftests A dashboard of results is now also updated automatically based on automatic tests: https://kdevops.org What have we learned from all this effort so far? And what lies ahead for the roadmap? If you want to contribute and help how do you do that?