December 11, 2016
 
 
RSSRSS feed

Linux 3.20 Likely to be Renumbered as Linux 4.0

  • February 16, 2015
  • By Sean Michael Kerner

Back in November of 2013, when the Linux 3.12 kernel was released, Linus Torvalds first began to talk about about Linux 4.0

Linux 4.0, much like Linux 3.0 isn't about any major milestone or API compatibility feature in the Linux kernel, but rather is just an arbitrary number.

"We're getting to release numbers where I have to take off my socks to count that high again," Torvalds wrote in a Linux Kernel Mailing List post in 2013. "I'm ok with 3., but I don't want us to get to the kinds of crazy numbers we had in the 2.x series, so at some point we're going to cut over from 3.x to 4.x, just to keep the numbers small and easy to remember."

Now with the merge window for Linux 3.20 Torvalds is ready to make the big number change, but first he wants input from Linux users. In a Google Plus post Torvalds wrote;

We're slowly getting up there again, with 3.20 being imminent, and I'm once more close to running out of fingers and toes.

I was making noises about just moving to 4.0 some time ago. But let's see what people think.

As of February 16, there have been 22,874 votes cast and the winner at this point is for Linux 4.0 at 56 percent.

The poll has also solicited 500 comments with a wide range of views on why to stick with Linux 3.20 or to move to Linux 4.0

From a feature perspective Linux 3.20 (or 4.0 if it gets renamed) will in fact usher in a new era for Linux with a major feature added to the kernel. That major feature is the introduction of live kernel patching, which a joint effort from Red Hat and SUSE.

In his Git Pull request developer Jiri Kosina wrote:

It provides a basic infrastructure for function "live patching" (i.e. code redirection), including API for kernel modules containing the actual patches, and API/ABI for userspace to be able to operate on the patches (look up what patches are applied, enable/disable them, etc). It's relatively simple and minimalistic, as it's making use of existing kernel infrastructure (namely ftrace) as much as possible. It's also self-contained, in a sense that it doesn't hook itself in any other kernel subsystem (it doesn't even touch any other code). It's now implemented for x86 only as a reference architecture, but support for powerpc, s390 and arm is already in the works (adding arch-specific support basically boils down to teaching ftrace about regs-saving).

Sean Michael Kerner is a senior editor at LinuxPlanet and InternetNews.com. Follow him on Twitter @TechJournalist

Sitemap | Contact Us