Ubuntu Kernel Next

Normally in Ubuntu's development cycle, we don't begin work on the kernel for a release until that release opens for development.

We are starting something new this time around. Now that 2.6.26 is released, and the kernel in Intrepid/8.10 (our current development cycle) is pretty stable, we have opened up a new git tree called ubuntu-next. Do not confuse this with linux-next, they are different concepts.

We are not spending a lot of time adding features to this tree. It is basically a rebase of all of our patches on top of the latest kernel in linux-2.6 upstream git. Our patches are consolidated and given some consistency (and a few pushed upstream).

At regular intervals, binary packages of this tree will be made available (usually at -rc milestones from upstream). In fact, the first installment of these are now available at:

http://kernel.ubuntu.com/pub/next/2.6.27-rc2/

I've built them for Hardy/8.04 and Intrepid/8.10. The only difference between Intrepid and Hardy is the compiler, which means your dkms and other third-party module recompiles should work :)

A few points to remember when using these:

• They are not guaranteed stable, or even to be able to boot. Keep away from small children.


• These images will not be supplied in a PPA or any other APT type repository. We need a barrier to prevent people from just adding these to their systems wholesale.


• We will not provide respins of linux-restricted-modules or any other modules package in the Ubuntu archive with these. Headers are provided, so use them if you need to.


• DO NOT (and I can't say this enough) file bugs on these packages. They will be ignored.


• DO (and I can't say this enough either) feel free to reproduce your bugs against official kernels with these kernels. It's a good data point to know whether the bug has been fixed by a newer kernel


• DO NOT (and I will make physical threats on this one) pump these packages into a public APT repo and tell the world so that it is "easier" to use bleeding edge stuff. If folks don't know how to install these packages, they surely don't need to be running them (we wont help them fix things after trying them).


• DO NOT ask us to put this into Intrepid/8.10 3 weeks before RC just because it makes your mouse stop squeaking whenever a cat is near the computer. Honestly, this kernel isn't going to get the same testing, and we have deadlines for a reason.

Other than that, enjoy.

Ubuntu Kernel Team IRC Meeting

Our next team meeting is August 5th (Tue) at 16:00 UTC. We invite any and all community members to participate. Read our agenda and see what we've done in the past. Quick note, we've been slacking on this important event for awhile now, and are trying to get things rolling again.

Ubuntu DKMS Presentation

At the Ubuntu Kernel Sprint in Lexington, Mass. this week, I did a presentation on how to create a simple package which utilizes DKMS. For those that don't know, DKMS is a distribution agnostic way to deliver driver source that is not prone to breakage when the kernel ABI changes.

When a new kernel is installed or booted, the driver is actually rebuilt against it automatically.

This is a 20 minute presentation, complete with an example package. There is a video of the talk in OGG format. It will be uploaded to the Ubuntu Dev video channel soon (in case you don't want the 1.4G file I have).

Have fun, and please don't hesitate to ask any questions.

http://kernel.ubuntu.com/~bcollins/dkms-presentation/

NOTE: I am in the process of uploading the ogg, so be patient:

-rw-r--r-- 1 bcollins bcollins 1444484439 2008-07-16 15:29 dkms-presentation.ogg
94a9c16c6fdb2593a19737ae6f7b9aac  dkms-presentation.ogg

UPDATE: Here's a smaller file. I hope the quality is good enough to read the projector:

-rw-r--r-- 1 bcollins bcollins 246894559 2008-07-17 12:48 dkms-presentation-small.ogg
61248c1baf4f708e3b040361e977eee0  dkms-presentation-small.ogg

Canonical and the Linux kernel

There's been a lot of discussion recently about Canonical and it's contributions to upstream, mainly due to an off-the-cuff comment by GregKH on a google video, and mainly in relation to the Linux kernel. Greg's statement, while correct when compared to his data, was incorrect because of improper data collection.

Greg did some data gathering to show where kernel contributions come from, based on the history in the git logs, and associating email addresses of authors with companies.

During this presentation, Greg said that "Canonical does not give back to the community". While I could do pages about how this blanket comment is completely baseless, due to the fact that he is using one numeric value from one bit of history, I wont go into that now.

What I want to clarify are the numbers, since I can prove them with facts. I don't make any claims that this data means we do huge amounts of work, or that we compare favorably to other companies. I just want people to know that the numbers you heard are wrong. I also want people to realize that these numbers, while important, are not a good metric of how much a company such as Canonical, SuSe or even Redhat contribute back to the community on a whole. Just remember, Ubuntu is a community driven distribution. It's not something we put out to appease the developers and community, it's the heart and soul of everything we do.

So, to get some corrections out:

GregKH: "Canonical only contributed 6 patches in 5 years"

BenC: First off, Canonical hasn't even been around for 5 years, so expressing the numbers in this way leads to some incorrect conclusions. Second off, using a check for ^Author with a canonical.com or ubuntu.com email address in the v2.6.25 tag of the upstream kernel tree, shows 91 commits (I should know the numbers, since 63 of those were from me). Granted, Redhat and SuSe outnumber us considerably, but then we don't have > 100 kernel developers on staff (we have less than 10).

So how did Greg make this mistake? After talking with him it seems he was only checking for canonical.com addresses. It was only recently that we started using canonical.com as a habit for upstream work (we used to use ubuntu.com).

Seems people like to harp on numbers, as inconclusive as they are. All I can say is, take a step back and look at the bigger picture. We're all working toward the same end, and we all have our contributions.

Kernel ABI and why it matters

Kernel ABI is the exported binary interface provided by the kernel, and accompanying modules. Most Linux distributions have a way of tracking this ABI to detect when the kernel's exported interfaces have changed, and thus, modules compiled for it may be in need of recompiling. Usually this results in the incrementing if an ABI number (on Ubuntu, it would be the "-2-" in 2.6.24-2-generic).

There are many extremes on how this ABI is handled, from taking expensive measures to ensure it doesn't change in a released distribution, to just not caring at all (not tracking it will be an idiotic extreme I wont even cover).

In Ubuntu's case, we fall somewhere in the middle. We track it, and bump the ABI fairly reliably if _anything_ in our kernel ABI changes. We also try not to bump it in released kernels too often (security updates being an exception), but we don't put much effort into preventing it, or guaranteeing a subset of symbols will never change over the lifetime of a product.

The general consensus has been (at least for me, I can't speak for Canonical on this point) is that the only things that cared about ABI bumps were proprietary and/or third party drivers. For open-source third-party drivers, we've recently been pushing the use of DKMS. For proprietary drivers, I've been all for letting the vendors deal with keeping up with us.

However, kABI has more ramifications than just proprietary modules. Many certifications are based on the kABI it is running under (think Oracle, VMware, etc). When we bump the kABI, we in affect force a minimal recertification. This isn't good for an enterprise Linux distribution.

So it seems that things will change. For Ubuntu to be considered in certain installations, kABI will need to have strict guidelines and criteria. We'll need to justify post-release kABI bumps and do more work to rewrite security patches to avoid changing the kABI.

A bit of preparation for this has already taken place in Intrepid's kernel (based on 2.6.26). A new kABI checker has been implemented. This checker has always been there, and it runs at build time, but has been very basic and dumb. Now, it has much finer grain checks, and will be expanded to support white/black lists in which we will only bump the kABI if it affects major parts of the kernel (no more kABI bumps for appletalk, sorry guys).

You wont notice much when this happens. You probably wouldn't have known if I hadn't told you. Rest assured that it wont adversely affect our range of hardware support. Perhaps it will mean you have to do less compiling for DKMS packages on your system :)