Lucid Arm Kernels

Andy Whitcroft apw at
Tue Nov 3 18:08:13 UTC 2009

The purpose of this email is to start to document and discuss the plan
for the existing ARM branches (imx-51 and mvl-dove) for the Lucid cycle.
It will also describe the implementation of this plan in particular
indicating where we have to deviate from that plan due to external

The Problem: Last cycle it took a very very long time to get working
kernels for the ARM boards and this reduced the time available for the
mobile teams to complete the userspace porting for these platforms.
Generally pushing us late into the cycle and up against the freezes.

The Logical Plan: The plan is to keep the ARM branches back on the
Karmic kernels until such time as a stable kernel replacement is ready
for those platforms.  We would maintain the kernels in Karmic as normal
and copy those kernels forward to Lucid as they are updated.  When and if
a replacement kernel is available for a platform we would then break the
link between Karmic and Lucid and update Lucid only to the updated version.
We do not envision the ARM kernel would be newer than the distro kernel.

Issues: There are a number of issues which lead us to not be able to use
the exact same kernel source and binaries for both Karmic and Lucid
going forward:

1) the archive does not allow a package to have the same filename in two
   releases beyond the initial copy from Karmic to Lucid,
2) the compiler in Lucid is likely to be updated to a newer version than
   that in Karmic and we desire the kernel to be compiled with the same
   compiler as installed on the system, and
3) the archive is being rebuilt for Lucid using arm-v7 as a base and
   we desire the kernel to be compiled correctly (does this affect the

The first of these throws up additional issues, particularly in combination
with 2 & 3.  If the kernel version cannot be the same in the two series
then we have to maintain separate version numbers in each.  Talking this
through with the archive admins there is one simple requirement, the
version numbers must not match in the two series and must be higher in
the later series to make upgrades work as expected.

Option ~karmic1: The common way to deal with this is to upload the updated
package to Lucid (the newer series) and then update the changelog leader
as below and re-upload for Karmic (the older series); indeed SRU policy
tends to encourage this through an implied requirement that a fix is
in Development before being SRUd.  So we would build a source package
as normal, then modify the changelog as below and rebuild the source
package again:

    linux-mvl-dove (2.6.31-208.17) lucid; urgency=low

    linux-mvl-dove (2.6.31-208.17~karmic1) karmic-proposed; urgency=low

So we can build the very same source tree into two very similar source
tarballs and upload them both in a scriptable manner.  We would likely have
the branches in only one of the repositories (perhaps Karmic as if we get
an updated version for Lucid we would want to put that only in Lucid).
We would then work on the branch as normal, but build and upload two
source packages as above.

Now this works pretty nicely until and if we have to diverge the two trees.
If the new Lucid version is a different base kernel version (say 2.6.32)
then we have no issue we simply start the new branch in Lucid and we are
good.  However if we got a complete rewrite of one of the ARM patchsets
at the same base version, then we would have to work to split the version
numbers as the ABIs could no longer be in lockstep.  The obvious solution
there is to simply jump the Lucid ABI number to an unused range (say 600)
and continue from there.  The main issue here is knowing where to find a
lucid kernel source for arm, and knowing where you should be uploading to.

Option lucid1: We should also be able to do the inverse working in karmic
and postfixing for Lucid, still uploading Lucid first:

    linux-mvl-dove (2.6.31-208.17) karmic-proposed; urgency=low

    linux-mvl-dove (2.6.31-208.17lucid1) lucid; urgency=low

This would have the advantage that the branch would be in the repository
which the version first appeared, it would also be configured to upload
to that repository.  The same caveats would apply in the face of a
divergance as do for the ~karmic1 option.

Option split ABI: We could alternatively start from day one by splitting
the ABI and handling both trees in lock step but as concurrent branches.
Applying changes to Lucid, uploading there, then cherry-picking those
back into the Karmic repo and uploading there as well.  Here we would
move to the split ABI mode immediatly.

    linux-mvl-dove (2.6.31-600.1) lucid; urgency=low

    linux-mvl-dove (2.6.31-208.17) karmic-proposed; urgency=low

Each of these options has issues.  In the ~karmic1 option we have more
trouble finding the kernel source for a specific branch likely you
would find the Lucid branches in the Karmic tree, but configured for
Lucid upload.  In the lucid1 option you would at least find the tree
in the git tree for the series in which it is based, and configured for
that release.  However in both of these the changelog is necessarly wrong
in the postfixed versions for all but the very last changelog.  The split
ABI option would allow divergence but require greater effort maintaining
the two trees before they diverge as we would maintain both trees manually.

I feel that the ~karmic1 version is probabally the most correct as the
development release changelog is more pure going forward.  But that is a
little more complex to understand as the Lucid main branch would be in
the Karmic tree.  The lucid1 option most directly matches our desired
functionality, but produces a less pure changelog in development.

I am tending to the lucid1 option at this time as it keeps the less
obvious handling in Lucid for now and we can upgrade to split ABI at any
time should we find it is not working.



More information about the kernel-team mailing list