Ubuntu Intrepid kernel open for business (almost)
tim.gardner at canonical.com
Fri Apr 25 17:57:11 UTC 2008
Tim Gardner wrote:
> I've started a git repository for the Ubuntu Intrepid Ibex kernel:
> Intrepid is based on the recently released 2.6.25 kernel and is a work
> in progress. I'm currently working through and applying the SAUCE
> patches from Hardy, at least those that still make sense. I'll make an
> announcement later this week when I think its ready for x86/x86_64
> building and testing. Once I can build all flavours I'll begin rebasing
> against the upstream kernel, nearly as frequently as Linus updates his
> tree. This process will continue until we decide which kernel and stable
> tree to settle on. I think it will almost surely be 2.6.26.
> Note that I said rebase, not merge. The prevailing opinion (with which I
> agree) is that rebasing is evil if you are sharing the repository.
> However, the one important benefit of rebasing is that it _does_
> preserve the commit SHA1 values from Linus' tree. This means that when
> making a LaunchPad report do not reference a SHA1 commit ID that is
> unique to Intrepid because it _will_ change on the next rebase. Only
> commit IDs from Linus' tree remain constant.
> The Intrepid development cycle will also be a good opportunity to make
> use of the daily kernel build infrastructure that was developed for
> Hardy, but was never turned on. I'll make an announcement when that gets
> cranked up.
> The Intrepid kernel is a straight clone of Linus' tree. However, there
> are lots of little changes to the Hardy kernel that we want to carry
> forward, SAUCE patches not withstanding. The first thing I did was to do
> a merge of the 2.6.25 kernel into a temporary Hardy tree, resolve the
> 147 conflicts, then diffed the merged Hardy tree against the clean
> 2.6.25 tree. There are lots of cosmetic differences which, though minor,
> are going to cause confusion in the future. Its one of the main reasons
> I chose to start Intrepid from a clean tree rather then a merged tree
> (besides having some ugly rebase issues). There are also some
> substantial diffs related to AppArmor. We need to decide if the security
> regime for Intrepid is AppArmor or SMACK.
> The other benefit of weeding through the merged Hardy v.s. clean 2.6.25
> diff is that it points out where we have been negligent in getting minor
> patches published upstream, e.g., quirks, black listings, etc. I'll be
> generating a bunch of patches that should go to the stable kernel as
> well as upstream.
> There is some good information about what is happing in the 2.6.25
> kernel at:
> As you can see, there is some pretty cool stuff coming down the pipe.
> Its gonna be a busy summer.
I pretty much have all of the Hardy diffs merged into the Intrepid git
repository. You can see the leftover differences at
A note about SAUCE patches - It used to be that we used the SAUCE
specifier in the commit log to denote a patch that will never go
upstream, e.g., a special sauce patch. However, especially with
Intrepid, there are no (or very few) patches that couldn't go upstream.
So, I've changed the semantics of SAUCE to mean 'any patch that modifies
kernel sources or Kconfig'. That will help distinguish administrative
commits from real source patches.
I'll be working throughout the Intrepid development cycle to get as many
of the SAUCE patches accepted upstream as possible. Hopefully by start
the 9.04 development cycle there will be far fewer SAUCE patches that
need to be ported.
Now, on to boot testing and LUM.
Tim Gardner tim.gardner at ubuntu.com
More information about the kernel-team