Ubuntu Wiki

History of Debian/Ubuntu kernel development

Throughout the history of Debian, the kernel has been maintained in many ways. Over time, the maintenance of the kernel had to be simplified due to the ever growing list of architectures, security updates, and different flavors being supported.

Probably the most notable of these methods was the dpatch system, where by each patch is stored in debian/patches/, with a common and sometimes per-arch list in debian/patches/00list*.

This system had many advantages over previous methods. Each patch could be modified or removed individually. It allows for easier sync with upstream, and allowed certain patches to be applied just for certain architectures. This is very similar to what quilt does (and was around long before quilt), however it was very generic and didn't have a lot of the features that quilt does.

When Ubuntu started, naturally, it kept this method. It can be seen as far back as warty, and up through breezy.

When dapper development started, it was decided to shift to a more "kernel" like source maintenance system. This meant moving to a Git tree. Instead of keeping this dpatch method, patches were applied directly to the tree. This had many benefits over the previous method:

• Merges were done in-tree. We no longer had to deal with a cascade of merge issues for several dozen patches when moving from one kernel version to another.
• Maintenance across versions (e.g. for security updates) was sped up considerably. Instead of creating dpatches for fixed security issues, it was only necessary to git-cherry-pick the changes, or merge from the appropriate 2.6.x.y Git repository.
• Ease of following a development line. Prior to this, following the current linux-2.6.git was a painstaking process. Using a git-tree, it is possible to sync to the in-development tree daily if not more.

So, the move was made, but basically it was no more than our previous way of doing things, just flattened out and using an upstream supported source control. This had a lot of drawbacks, not so much for the people working on the Ubuntu kernel, but for people that had an interest in working with Ubuntu and its kernel.

One problem with maintaining the Ubuntu kernel in-tree is that the revision history isn't as tidy as the upstream kernel, for example. There are lots of commits geared at just debian/* updates. This has prompted a rework in the way we are going to use Git for the Ubuntu kernel.

The New Git Tree

For the next Ubuntu release, <edgy+1>, we will be starting from scratch with a new development paradigm. Development will begin with the current 2.6.19 Git tree. All patches and external drivers will be forward ported to this tree, but with several main goals kept in mind.

External drivers

Until now, all externally added drivers (e.g. ipw3945) were added to the kernel tree in the same place they would have been added as if by upstream themselves (e.g. drivers/net/wireless/ipw3945).

This made it difficult to know what drivers had been added in our tree. All externally added drivers will now be added to a new ubuntu/ top level directory. This directory will be very much like the drivers/ directory.

With this setup, it is very easy to disable all of the Ubuntu added drivers with a single config option.

Updating in-tree

Patches to the stock kernel source will be minimal, and will be required to be sent upstream as needed. Some patches are Ubuntu local changes, and of no interest to upstream.

In some cases, when the kernel version we are following is final, we need to update to some newer version of just a portion of this tree. Examples of this are DRM/AGP (to support newer video chipsets) and ACPI. The old way was to update these in-tree. Instead, these will now be completely ported in the ubuntu/ sub-directory. The stock kernel portions will be disabled via kbuild mechanisms.

debian/changelog

During Dapper and Edgy development (the two releases for which we have used Git), updating the debian/changelog file was done in separate commits from the actual changes. This lead to several issues:

• Updates to this file were done manually, and entailed some skew from the actual Git history.
• Merges with upstream were usually not itemized in this changelog.
• It was very difficult to match a debian/changelog entry with a matching Git commit.
• For each actual commit to the source, there was usually an accompanying commit to debian/changelog.

The new repository will have automatic itemized listings of the Git history in debian/changelog, similar to what is done for the Linux shortlog. This will be done at each release of the kernel (upload to Ubuntu repository). To get a running list of changes from the last release, one needs only to do:

debian/rules printchanges | less

This will include the upstream changes merged, as well as Ubuntu specific changes, and will be annotated as such. Format will be suitable for appending directly to the top of debian/changelog.

Commit templates

The commit templates in debian/commit-templates/ are there to make things easier. The format is made to help parsing for debian/changelog, but also for any other automated tools. Read the templates for explanations of what tags supported. Generally a commit to Ubuntu will be done like:

git-commit -s -F debian/commit-templates/<template> -e

Replace <template> with the name of the actual template to use.

The committer will fill in the appropriate information for the commit as outlined in the template.

Conclusion

The hope is that this new infrastructure and development model will make the Ubuntu kernel git repository easier to use for everyone. Comments and suggestions are welcome, and can be sent to the Ubuntu Kernel Team.

CategoryKernel