add arm64 LTS targets #40
Conversation
|
Fixes #35 |
nickdesaulniers
force-pushed
the
config
branch
2 times, most recently
from
9241f4c to
c0aea26
Compare
|
Not sure if 4.19 is also an LTS branch? Seems kind of close to 4.18, though? |
nickdesaulniers
force-pushed
the
config
branch
from
35c79b6 to
5e625b7
Compare
|
needs a rebase on #41 too. |
4.19 is LTS. 4.18 isn't. |
|
@groeck do you know who maintains: https://www.kernel.org/ ? It says 4.18 AND 4.19 are stable. Thanks for the the clarification though, I'll fix that in my patch. |
Misunderstanding. "stable" does not mean "longterm". I assume they'll update the 4.19 tag to "longterm" in due time, maybe after 4.18 is marked EOL. If you search for "Linux LTS 4.19" you'll find references to 4.19 being the next longterm stable release. |
|
It's listed as an LTS kernel on the releases page: https://www.kernel.org/category/releases.html There's an FAQ about why LTS is marked as stable on the front page: https://www.kernel.org/category/faq.html |
.travis.yml
Outdated
| env: ARCH=arm64 REPO=4-18 | ||
| - name: "ARCH=arm64 REPO=4-14" | ||
| env: ARCH=arm64 REPO=4-14 | ||
| - name: "ARCH=arm64 REPO=4-9" |
There was a problem hiding this comment.
Should 4.4 and 4.9 be added just yet since support is not upstream yet?
There was a problem hiding this comment.
I guess it's a question of having things wired up, even if they're red on day one. Depends on what we want to do if/when a target goes red; do we want to disable it, or let every cron be red until a fix lands?
I'd prefer to have some automated testing so we can collect warnings from the logs. Maybe we can settle the question about regressions later.
There was a problem hiding this comment.
I'd argue we should keep everything green. Since 4.14 and 4.19 should work fine and the case block below is super easy to extend with new version (and 4.4 and 4.9 can even remain), I suggest we keep 4.4 and 4.9 off of the matrix until the core Clang support is added to those branches upstream. Alternatively, we could create a linux-stable repo on our organization (or branches on the main linux repo) and have the backports there until integration upstream just for early testing.
There was a problem hiding this comment.
Ok, I've updated the patch set. I want at least one run presubmit, just so we have logs we can point to from our issue tracker or whatever to keep track of what needs to get backported. Will comment out the configs once we get a run.
nickdesaulniers
force-pushed
the
config
branch
from
5e625b7 to
6a24174
Compare
|
I need to fix the variable
|
|
Ah yes should be |
nickdesaulniers
force-pushed
the
config
branch
from
6a24174 to
9cc44e3
Compare
|
4.19 needs ClangBuiltLinux/linux@2a6c7c3 4.4/4.9 need the series mentioned in #35. Hopefully that patch makes it into 4.19.2, Greg seems to be churning through his backlog pretty quickly. Since it is only one patch that should be needed, we could add a It'll be tested here, I have to run off to work: https://travis-ci.com/nathanchance/continuous-integration/jobs/157777563 |
|
I just got an email that @gregkh added the -fcall-used-x0 to stable. (an hour after your post @nathanchance ) |
|
Yeah ah the irony lol |
nickdesaulniers
force-pushed
the
config
branch
2 times, most recently
from
bfb51d6 to
8252eb1
Compare
|
ok, now that we have a presubmit run (build 225), let's commit just 4.14 support. |
Did the ORC unwinder just become default on? |
|
No, my '-pipe' patch got merged so the |
|
|
|
It might be worth setting that globally if no command is meant to fail. |
Fixes the case were $ARCH was not set when driver.sh was invoked. It needs to be an env var for the kernel's make; driver default initializes a local shell variable. It needs to re-export $ARCH the env var.
Still need to pick some configs in travis.yml.
Let's start with arm64 for now, then add more arch's later, if people care about them. Looks like 4.14 is supported, but 4.19, 4.9, and 4.4 need more backports before they can be enabled.
nickdesaulniers
force-pushed
the
config
branch
from
8252eb1 to
bb98314
Compare
this obviously conflicts with #39 , so will rebase on top.
@Ajs1984 and I discussed today seeing what was broken in these branches in stable, and sending the relevant backports to @gregkh rather than landing them in Android common kernels, since they merge down from LTS anyways.
We should move these to cron jobs (post submit), but doing so now would make it so that these new targets aren't tested. Once we get a run, I'll either make the cron, or comment them out (if they're super broken) with a patch on top of this PR.