2396 2012-05-02 22:52:28 +0000 Integrate LTSI into linux-yocto-dev 2013-03-26 15:44:34 +0000 1 1 6 Yocto Project Subprojects Kernel kernel-tooling 1.2 x86 Multiple VERIFIED FIXED High enhancement 1.4 M4 1 dvhart bruce.ashfield corneliux.stoicescu jessica.zhang mihai.lindner richard.purdie song.liu yp.kernel.watcher yp.watcher --- --- --- oldest_to_newest 21032 0 dvhart 2012-05-02 22:52:28 +0000 We've discussed this with Greg KH regarding LTSI support in Yocto. The agreement was to support each LTSI release until the next LTSI release was made. Rather than make special LTSI kernels, each linux-yocto release that aligns with an LTSI release should track that LTSI release. For now that is 3.0. Whether or not the Yocto 1.3 linux-yocto version aligns with an LTSI release is still up in the air as far as I know. This involves ensuring standard/base includes the LTSI tree and that the dependent branches derive from it. I'm interested to see if the rt-3.2 stable tree can continue to apply to the LTSI release. I hope so. 21061 1 bruce.ashfield 2012-05-03 14:27:16 +0000 I was hoping to pick up LTSI support and sync on 3.4. I'll contact greg again to see what his plan are in this area. Do you mean 3.0-stable -rt for the last part ? I'm thinking you do. For the 3.0 tree, since we've had it out for a while, I'll have to fork the repository and rebase on top of LTSI and move all old releases to the 3.0.x tree that I created for linux-yocto-3.0-1.1.x. But there's a complication. The 3.0 tree that was updated for 1.2 has fixes that shouldn't really go back to 1.1.x (if there are anymore), so we either stack them on there and do no more 1.1.x updates and re-do the 3.0 tree to be on top of LTSI. We can easily get into tree explosion in a scenario like this. There is an option to change branch names, and stack all of the old releases branches into a single -stable tree. That prevents tree count explosion. Alternatively, we wait until the next LTSI and build on top of it from the beginning and it won't cause a problem like this. 21063 2 dvhart 2012-05-03 14:53:48 +0000 (In reply to comment #1) > I was hoping to pick up LTSI support and sync on 3.4. I'll contact greg > again to > see what his plan are in this area. > > Do you mean 3.0-stable -rt for the last part ? I'm thinking you do. Yes, oops. This one specifically: http://kernel.org/pub/linux/kernel/projects/rt/3.0/README There is also one of these for 3.2 incidentally. Note that they are guranteed not to rebase! > > For the 3.0 tree, since we've had it out for a while, I'll have to fork > the repository and rebase on top of LTSI and move all old releases to the > 3.0.x tree that I created for linux-yocto-3.0-1.1.x. But there's a > complication. > The 3.0 tree that was updated for 1.2 has fixes that shouldn't really go > back to 1.1.x (if there are anymore), so we either stack them on there and > do no more 1.1.x updates and re-do the 3.0 tree to be on top of LTSI. > > We can easily get into tree explosion in a scenario like this. > > There is an option to change branch names, and stack all of the old releases > branches into a single -stable tree. That prevents tree count explosion. > > Alternatively, we wait until the next LTSI and build on top of it from > the beginning and it won't cause a problem like this. That does get messy. And of course changing this tree would result in changing the kernel for 1.2, which I don't want to do. However, 3.4 will be out very soon, and it seems to me we may want to have a linux-yocto-3.5 for the 1.3 release. I'd really rather not have both. At the same time, we are behind here and we need an LTSI kernel. At this point, I'm thinking we should release a 3.4-LTSI kernel for 1.3. This is consistent with the goals of 1.3 (fix, polish, etc.). The more I think on it... the more I like the idea of a 3.4 LTSI only for 1.3. It would give us extra time to get the policy and config refactoring and the various tooling items done WELL and RIGHT. We would need to confirm with Greg that this aligns with his goals. Thoughts? 21065 3 bruce.ashfield 2012-05-03 15:06:38 +0000 (In reply to comment #2) > (In reply to comment #1) > > I was hoping to pick up LTSI support and sync on 3.4. I'll contact greg > > again to > > see what his plan are in this area. > > > > Do you mean 3.0-stable -rt for the last part ? I'm thinking you do. > > Yes, oops. This one specifically: > http://kernel.org/pub/linux/kernel/projects/rt/3.0/README > > There is also one of these for 3.2 incidentally. Note that they are > guranteed not to rebase! perfect. We agree there. > > > > > For the 3.0 tree, since we've had it out for a while, I'll have to fork > > the repository and rebase on top of LTSI and move all old releases to the > > 3.0.x tree that I created for linux-yocto-3.0-1.1.x. But there's a > > complication. > > The 3.0 tree that was updated for 1.2 has fixes that shouldn't really go > > back to 1.1.x (if there are anymore), so we either stack them on there and > > do no more 1.1.x updates and re-do the 3.0 tree to be on top of LTSI. > > > > We can easily get into tree explosion in a scenario like this. > > > > There is an option to change branch names, and stack all of the old releases > > branches into a single -stable tree. That prevents tree count explosion. > > > > Alternatively, we wait until the next LTSI and build on top of it from > > the beginning and it won't cause a problem like this. > > That does get messy. And of course changing this tree would result in > changing the kernel for 1.2, which I don't want to do. However, 3.4 will be > out very soon, and it seems to me we may want to have a linux-yocto-3.5 for > the 1.3 release. I'd really rather not have both. At the same time, we are > behind here and we need an LTSI kernel. At this point, I'm thinking we > should release a 3.4-LTSI kernel for 1.3. This is consistent with the goals > of 1.3 (fix, polish, etc.). This was the rough plan, to take a stutter step in 1.3 and align with LTSI. The kernel will be slightly older .. but better and longer supported, and it meets the 1.3 goals nicely. linux-yocto-dev will pick up the slack for a newer kernel. > > The more I think on it... the more I like the idea of a 3.4 LTSI only for > 1.3. It would give us extra time to get the policy and config refactoring > and the various tooling items done WELL and RIGHT. We would need to confirm > with Greg that this aligns with his goals. We completely agree. We just need to make sure that LTSI moves to meet us :) Bruce > > Thoughts? 23791 4 dvhart 2012-08-03 16:57:39 +0000 This won't happen until 1.4 as LTSI-3.4 isn't likely to be released prior to November 2012. 26763 5 richard.purdie 2012-10-19 14:28:53 +0000 Status -> WaitForUpstream 27501 6 dvhart 2012-11-15 21:40:58 +0000 We want to do this as soon as possible, but we are dependent on LTSI 3.4. We should have this done by M3 at the latest to allow for a full milestone of testing the LTSI kernels. Marking as M3. 28913 7 bruce.ashfield 2013-01-17 16:45:55 +0000 Patches have been merged, staged and build tested. http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/commit/?id=28a6f08b98bf888a3dd5ed8bd00d41f925bf9ee0 boot testing remains before the tree will be pushed for general use. 28954 8 bruce.ashfield 2013-01-18 16:57:07 +0000 commit 09d0bc521ad34473acf2ec4a00a69c3e3183f7d9 Author: Bruce Ashfield <bruce.ashfield@windriver.com> Date: Fri Jan 18 00:19:31 2013 -0500 linux-yocto/3.4: integrate LTSI-3.4 Updating the linux-yocto-3.4 SRCREVS to activate the merge of the 3.4.25-ltsi tree: http://git.linuxfoundation.org/?p=ltsi-kernel.git;a=tag;h=refs/tags/v3.4.25-ltsi The pristine patch queue can be seen on the "ltsi" branch in the repository. This branch has been merged into the standard/base branch of linux-yocto-3.4 and to all BSP branches in the tree. LTSI based BSPs or features are not activated as part of this commit, they are controlled by the meta branch of the kernel repository and are activated in separate patches. [YOCTO #2396] (From OE-Core rev: 8f03ebe9b164e0c0493c56d9eb2e7d0b039832f1) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 29858 9 bruce.ashfield 2013-02-15 15:10:19 +0000 LTSI is now merged into the 3.4 tree. It can be seen as the discrete "ltsi" branch, which is also merged into each and every BSP. There's no explicit action required to "use LTSI", you simply get it in each build. The features can be enabled via fragments as required, or left latent. 31172 10 corneliux.stoicescu 2013-03-26 14:50:47 +0000 Test case added: https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=742 31174 11 mihai.lindner 2013-03-26 15:44:34 +0000 Build Configuration: BB_VERSION = "1.17.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Gentoo-n-a" TARGET_SYS = "i586-poky-linux" MACHINE = "atom-pc" DISTRO = "poky" DISTRO_VERSION = "1.3+snapshot-20130326" TUNE_FEATURES = "m32 core2" TARGET_FPU = "" meta meta-yocto meta-yocto-bsp = "master:f36926a264190e6202830e8520b41b30ae77ea43"