Maintaining a Linux Kernel for 13 Years? You Must be Kidding Me. We Need at Least 30?
summary
CIP aims to extend maintenance decades by tracking CIP kernel (4.4 LTS), collecting member configurations, and running a local kernelci service to test changes. Practical limits include the year 2038 limit on 32‑bit time, hardware EOL after about 10–15 years, and increasing backport difficulty as kernel internals change. Scope reduction to arm64 and x86 only cuts the amount of code to review. Expect multiple maintained branches, member-driven fixes, and the decision that some obscure non‑security fixes are not worth backporting.
AI-written summary · about
chapters (22)
- 0:00Introduction
- 1:36Agenda
- 2:16Life Cycle
- 4:09Industrial Perspective
- 4:53Power Plants
- 5:46Linux Kernel
- 6:23Why are we doing this
- 7:34First strategy
- 8:22Second strategy
- 15:31Scope of maintenance
- 17:05Fixed bugs
- 18:53Collaboration
- 20:37Any Questions
- 22:44A Better Strategy
- 23:29Future Plans
- 24:31Year 2038
- 26:22Back ported
- 27:29Shipment plans
- 28:07Development effort
- 29:15CIP branch
- 30:47CIP kernel
- 32:34Debian vs CIP
related talks
39mThe End of the Paved Road: Maintaining Linux Kernel 4.4 Beyond LTS
49mLong-Term Maintenance, or How to (Mis-)Manage Embedded Systems for 10+ Years
36mStuck in 2009 - How I Survived
27mAn SRE guide to Linux Kernel upgrades
01h 15mCurrent Developments in the Linux Kernel
45mAn engineer's guide to Linux Kernel upgrades
34mAn SRE Guide to Linux Kernel Upgrades
24mContinuously Integrating the Upstream Linux Kernel on Hardware