FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 11-03-2009, 05:08 PM
Andy Whitcroft
 
Default Lucid Arm Kernels

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
constraints.

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
kernel?).

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
[...]

becomes:
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
[...]

becomes:
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
[...]

and:
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.

Thoughts?

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-03-2009, 07:56 PM
Loc Minier
 
Default Lucid Arm Kernels

On Tue, Nov 03, 2009, Andy Whitcroft wrote:
> 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
> kernel?).

Nah don't worry about toolchain flags being updated. In theory the
kernel sets them by itself already since it's a special binary and is
quite aware of the platform it targets.

--
Loc Minier

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-04-2009, 12:52 AM
Tim Gardner
 
Default Lucid Arm Kernels

Andy Whitcroft wrote:
> 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
> constraints.
>
> 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
> kernel?).
>
> 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
> [...]
>
> becomes:
> 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
> [...]
>
> becomes:
> 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
> [...]
>
> and:
> 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.
>
> Thoughts?
>
> -apw
>

In my opinion the only way to do this is 'Option split ABI' and carry
Lucid fsl-imx51 and mvl-dove branches in the Karmic repo. I realize the
naming is a bit unorthogonal, but its also possible that one or more of
the ARM flavours will eventually migrate to newer kernel versions during
the Lucid cycle. If that happens, then we'll start new branches in the
Lucid repo.

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 11-04-2009, 01:55 AM
Michael Casadevall
 
Default Lucid Arm Kernels

On Tue, 3 Nov 2009, Andy Whitcroft wrote:

> 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
> constraints.
>
> 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

Shouldn't be an issue, due to how packages build in pockets.

Upload to lucid: Compiled against lucid alone

Upload to karmic-proposed: Compiled in karmic chroot with karmic proposed,
security, and updates enabled.

Upload to karmic-security: Compiled in karmic chroot, with only security
repo enabled.

Upload to karmic-backports: Compiled in karmic chroot, with updates and
backports enabled.

> 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
> kernel?).
>

At least for imx51 kernels, there's specific logic in the Makefile to
override the compiler flags. All in-archive imx51 kernels have been tuned
for Cortex A8 processors since day one.

> 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
> [...]
>
> becomes:
> 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
> [...]
>
> becomes:
> 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
> [...]
>
> and:
> 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.
>
> Thoughts?
>

I think split ABI may be the way to go, although I don't claim to be an
expert in this. Given that we'll likely get a stack of patches with
additional bug fixes from SoC vendors, there is bound to be some patches
sooner or later that we only want to apply for lucid, or otherwise fails
to meet SRU criteria. Given that possibility, I think we should be prepared
to be able to handle different sets of patch in karmic-updates and lucid,
even if both trees are based around the same kernel version,

Michael

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 08:43 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org