LCA2009: That mysterious thing called the kernel

Sam Varghese
Wednesday, 21 January 2009 15:23

Opinion and Analysis

Corbet said the developers existed apart from their employers and there was no ownership of code; one had to surrender rights to the kernel project. No regressions of code were possible, not even to fix other problems.

Kernel developers had no right to insist that their code should be included, he said. All changes had to be justified and there was every chance that other solutions would win out - provided they were technically better.

There is one mainline kernel tree, otherwise known as Linus' kernel; this followed a two-to-three-month release cycle. Corbet said the schedule followed was a two-week merge period, followed by a period of eight to 12 weeks for stabilisation and then release.

Once a stable kernel was released, there would be occasional point releases if important updates were required - things like security fixes or severe bugs. This stable kernel was maintained for about six months.

Distributors had their own kernels which were based on the stable release but could include significant changes. This was especially the case with kernels in enterprise distributions and the maintenance period varied, Corbet said.

The kernel team had some development trees - one called Linux-next and the other called -mm which was maintained by Andrew Morton. Linux-next was the staging area for the next mainline kernel with patch integration and early testing taking place there.

The -mm tree was now based on Linux-next and it served as the collection point for miscellaneous patches and more early testing.

Corbet said those who wanted to get changes into the mainline kernel should target the subsystem trees as these fed into the mainline kernel. "Subsystem maintainers are the true gatekeepers, but their power is not absolute," he said.

When one member of the audience asked whether Torvalds' code was ever rejected, the great man himself took the mike and replied that it was possible that this could happen; he was lazy and hence sent his patches to others to test. If the patch came back to him after testing, he would always merge it but if it did not he would not bother about it.