Long Live the New LTS Kernel

It’s the most wonderful time of the year again! No, it’s not Christmas, but the beginning of a new cycle in the Linux microcosm. A few days ago, the Linux 4.1 kernel has been released, and chosen as the LTS kernel of 2015, becoming the most advanced long-term supported release. This is significant not only because the LTS releases are expected to be a usable base for the majority of embedded systems, but also because in a few months’ time the industry will have a new LTSI kernel that will be supported for at least the next two years. The merge window for the 4.1 LTSI kernel will most likely be opened in November followed by the usual validation and release processes.

Oh dear! So many acronyms, so much process! How about a bit of background to shed more light?

Not all kernels are created equal

2011 was a very busy year for the Linux community. It was the year someone (some  10 consumer electronics companies) somewhere (Prague) thought “you know what, these regular 2-3 releases a month do deliver valuable innovation to Linux users, but the rate of change in the kernel is creating challenges for the consumer electronic devices market.“

So, as a result of many long industry discussions, LinuxCon Europe kicked off the start of a new Linux Foundation project: the Long Term Support Initiative (LTSI). OK, that’s one acronym down.

Hosted by the Linux Foundation, the LTSI project aims to maintain a common Linux base to be used in a variety of consumer electronics products by creating and maintaining a long-term industry tree, expected to be stable in quality for the typical lifetime of a consumer electronics product, usually over two  years. LTSI kernels are chosen from the Long Term Stable (LTS) kernel candidates, see Figure 2. Another acronym down.

Fig.1 Linux Kernel Versioning Convention

Fig. 2 LTS and LTSI kernel cadence and selection

With an average of over 10,000 patches going into each recent kernel release, having a stable version that back ports features from the latest upstream code for a period of 2+ years is a pretty big deal. It solves maintenance issues in a collaborative way, the open source software way. Working systematically with Swiss watch like precision and predictability, the Linux kernel maintainers have been cranking out patches on a regular basis. Some kernels are more ephemeral, some are here to stay (in red below are the LTS kernels). Commits are back ported from the latest upstream version into the LTS versions. 3.14 LTSI will be EOL-ed in August 2016 and 3.10 LTSI in September 2015.

Fig 3. LTS kernels

Why it matters

LTSI kernels comply with additional rules and incorporate additional patches. The LTSI tree includes a set of vendor required patches, and has a different development process for gathering patches on top of the LTS versions.  The goal is to enable sharing additional patches among industries. These patches may focus on SoC additional drivers or kernel tools for instance. Transparency is also a cardinal component. The LTSI patch set is tested by contributors and the results are shared in the LTSI mailing list. There are also face-to-face meetings that cover a wide variety of discussions among companies regarding LTSI requirements, use cases and key issues. When it comes to deciding in-house patches versus upstream, the LF’s working group helps developers upstream their code so that the technology doesn’t become locked.

With every single hour of every single day, there are new applications and new features being developed. These developments either happened on the most stable version of kernel (the candidates for LTS kernels) or are being back ported to the LTSI kernels. The developments are encouraging innovation and stability. For combat against fragmentation and improve interoperability, other projects like the Yocto Project, are ideal. And, for the easiest transition from open source innovation to steady, reliable and foreseeable platforms, there are commercial vendors who do the heavy lifting so that teams can  concentrate on the differentiating features for their product, and not get stuck in risk mitigation procedures, and back porting activities.

We’re first!

So, how does Wind River work with the community and why can we enable a smooth and prompt transition from open source development into a risk mitigated commercial platform? Quite easy, the timeline below speaks for itself.

Fig.4 Integrating Open Source Developments into Wind River Linux 7

Consider this sample timeline for our current Linux platform, Wind River Linux 7. The stable Linux kernel was announced in the June-July 2014 timeframe. From August to October there was an LTSI merging window when developers submitted new patches and packages, so Wind River engineers worked with different community groups like the Yocto Project and kernel.org in order to leverage what was being developed and submitted.

The Yocto Project release occurred by the end of October. Usually the Yocto Project makes its releases on the latest LTSI and latest available released kernel (i.e. Yocto Project 1.7 was released with 3.14 LTSI and 3.17 kernels). Wind River released its commercially supported and Yocto Project-compatible Linux offering that December. The aim was to get the latest technological developments to any OEM that wanted to use Wind River Linux. One thing to consider though, is that using Linux is a long-term commitment. And although we based our product on the kernel that is/will be supported in the community for more than two years, Wind River’s rigorous maintenance practices (with its monthly update mechanisms) becomes especially crucial for teams after the second year, when the devices are already deployed in the field.

For now, the merge window for the 4.1 LSTI kernel is opening, and it will last for about 75 days. We will be there every step of the way, so that when we introduce the next Wind River Linux refresh, it will be highly relevant and effective from both a hardware enablement and features perspective.