Long-Term Maintenance, or How to (Mis-)Manage Embedded Systems for 10+ Years
summary
Claim: keep product kernels close to mainline, rebase annually and automate testing so security fixes reach devices in days not months. Work tested with Jenkins and board farm validation via LAVA, deploy with redundant A/B boot and staged rollouts. Expect about 100 CVEs per year in common components, plan ~2–4 weeks per year of maintenance plus 3–5 days monthly monitoring, and aim for incident response under one day for routine fixes. Annual rebases shrink custom patches and make community testing effective.
AI-written summary · about
chapters (7)
- 0:00Start
- 4:50The System's Life Cycle
- 8:59Observations
- 19:48Automated Testing
- 29:18Summary
- 31:25How To Work with Application Teams That Have Problems with the Platform Changing under Them
- 48:47Suggestions for Further Talks
related talks
34mMaintaining a Linux Kernel for 13 Years? You Must be Kidding Me. We Need at Least 30?
34mDelivering Security Fixes Continuously Into Your Embedded Linux
39mUsing Long Term Stable Kernel for the Embedded Products
31mDebian and Yocto Project Based Long-Term Maintenance Approaches for Embedded Products
33mUsing Open Source Software to Build an Industrial-grade Embedded Linux Platform...
17mAccelerating Development and Deployment of Updatable Linux-based Edge AI devices in the CRA era
55mThe Embedded Linux Problem
45mAn engineer's guide to Linux Kernel upgrades