On 5 August 2013 18:16, Mark Brown broonie@linaro.org wrote:
On 5 August 2013 03:45, Andy Green andy.green@linaro.org wrote:
- There seems to be two choices, linux-linaro-lsk and
linux-linaro-lsk-android.
I chose the android one, I assume it has the same "androidization" series on top that linux-linaro-core-tracking used at 3.10? Are there any other differences?
There are some patches to improve the performance of the interactive scheduler in there as well. Currently we didn't take John's branch in order to make it easier to track the Google stuff while we're preparing for release, that will get filtered in sometime this week.
I see, thanks.
There may be other stuff lurking in linux-linaro that I'm not aware of, everything is supposed to be individually selected for backport.
Literally linux-linaro I'm not sure is useful for anything, the tree LTs are basing on is linux-linaro-core-tracking.
It's composed by rebase and then merges, so it's easy to see what's in there from a quick git log.
https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git%3Ba=shortlo...
For tracking, we rebase our BSP patches on this every rc and get all the latest nice things like IKS and HMP coming in our tree with no drama.
For v3.10 what I've done is switch the basis from the v3.10 version of llct to your tree, and that went easily too.
- In our LT tree we patch mainline to remove all warnings coming with
our defconfig. Then if we see any warnings coming, we know it's our fault and we need to go fix it. Are you interested in taking a similar approach?
We will take suitably non-invasive warning fixes and obviously any actual bug fixes that are fixed in the upstream LTS but we won't actively go looking for warnings in anything that's not built for testing of LSK ourselves. There is no commitment to making things in the underlying kernel warning free.
Sounds reasonable.... attached is our current patch for your consideration. There's a permanent #warning about an unwind tables TODO this also knocks out the others are actual problems.
- Maybe this is too much thinking ahead, but shouldn't these lsk
branches be versioned, like linux-linaro-lsk-3.10? Otherwise when the next lsk version is announced there'll be a problem.
This is what I inherited, we'd certainly start versioning things when there's more than one LSK around but having a "this is the default version" pointer does seem useful. I was intending to add versioned branches as part of the official release (which should be 13.08 now Greg's announced v3.10 as a LTS).
If we start doing it shortly it's fine. Otherwise people who want 3.10-specific one will have no choice but to point at the "latest" one if that's all there is, and that will not always be 3.10. Having the default one mirror the latest versioned one sounds like the best of both worlds.
-Andy