Language Selection

English French German Italian Portuguese Spanish

Torvalds: How to Keep Linux Kernel on Course

Filed under
Linux

The rapid pace of Linux development appeared to hit a roadblock last year with the industry's decision to forestall development of the Linux 2.7 kernel. Linux vendors and developers wondered if tweaking a single, stable 2.6 kernel could work in practice.

According to open-source insiders, the move to create separate kernel trees for technology testing and bug fixes, which are then incorporated into the stable kernel when ready, has been a huge success, pleasing both kernel developers and the vendors who distribute the open-source operating system.

"I'm certainly pleased, and judging from the reactions we had at the Linux Kernel Summit in Ottawa a few weeks ago, most everybody else is too," Linus Torvalds, the founder of the Linux operating system, told eWEEK.

The biggest advantage of staying with 2.6.x was that developers do not have two different trees between which they need to port patches, which makes them happy, he said.

Linux vendors tend to like the move, because the upgrades are more gradual, rather than the huge, and potentially painful, jumps of the past.

This shift started at the 2004 Linux Kernel Summit with the decision to no longer have a separate kernel development tree, but to keep adding new features, technologies and patches to the existing 2.6 stable tree, Greg Kroah-Hartman, a Linux kernel developer with Novell, told attendees at the annual O'Reilly Open Source Convention last week.

That decision has spawned three separate 2.6 trees: The first is the mainline or stable kernel, known as 2.6.x and which is maintained by Torvalds; the second is known as the 2.6-mm tree, and is where technologies are tested before they get into the mainline kernel; and the third is the 2.6.x.y kernel (known as the .y kernel), which is for bug fixes only.

The .y kernel is governed by a set of strict rules, including that the fix has to be less than 100 lines, that it applies to something already in the mainline kernel, and there had to be a three-day public review of all patches to allow all involved parties time to express their view and to make sure that everyone bought in, Kroah-Hartman said.

There were 12 2.6.11.y releases, with just 507 lines added and 303 lines removed, "which is the way to just get things fixed and I think shows that this process is working. These fixes also go into the mainline release and the 2.6.11.y was dropped when the 2.6.12 release came out. There have been four 2.6.12.y releases so far, with the latest released last Friday," he said.

The 2.6.12.y releases have had just 169 lines added and 199 lines removed.

"We are not back porting big experimental things into the .y-series," he said.

But there needed to be a mechanism for testing new technologies, a place where they could be revised, updated and even removed before actually getting into the mainline kernel.

Full Article.

More in Tux Machines

Android/ChromeOS/Google Leftovers

Games: SC-Controller 0.4.2, Campo Santo, Last Epoch and More

Android Leftovers

Ryzen 7 2700X CPUFreq Scaling Governor Benchmarks On Ubuntu Linux

With this week's Ryzen 5 2600X + Ryzen 7 2700X benchmarks some thought the CPUFreq scaling driver or rather its governors may have been limiting the performance of these Zen+ CPUs, so I ran some additional benchmarks this weekend. Those launch-day Ryzen 5 2600X / Ryzen 7 2700X Ubuntu Linux benchmarks were using the "performance" governor, but some have alleged that the performance governor may now actually hurt AMD systems... Ondemand, of course, is the default CPUFreq governor on Ubuntu and most other Linux distributions. Some also have said the "schedutil" governor that makes use of the kernel's scheduler utilization data may do better on AMD. So I ran some extra benchmarks while changing between CPUFreq's ondemand (default), performance (normally the best for performance, and what was used in our CPU tests), schedutil (the newest option), and powersave (if you really just care about conserving power). Read more