Add LTS branches back to 4.4 #35
Comments
|
Given that the Clang patchset is out of tree for 4.4 and 4.9, how did you want to maintain that? Patch files or a whole repo? |
|
I spoke with @gregkh about this in person. IIRC, he said "if you need anything for building LTS in Clang just send it to me." We want them for Android common kernels anyways, so it's simpler to land things upstream from their in LTS and let them flow down. I just need to sit down and see what did we take into pixel kernels, or is upstream in newer versions of Linux that needs to get backported. |
|
I figured, @mkaehlcke had asked if Clang support could be added directly to LTS earlier this year: https://android-review.googlesource.com/c/kernel/common/+/654139 The Chromium backports were used for kernel/common (as I am sure you know 😛) and should have the upstream SHAs in the messages for inclusion in -stable. 4.4: https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/refs/sandbox/mka/llvm/v4.4 4.9: https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/refs/sandbox/mka/llvm/v4.9 The Pixel 2 kernel shipped the pre-polished patches it seems but all of those should have found their way upstream. I also did my own backports for 3.18 two separate times (purely for reference of commits, not to send to stable), including the core commits + some warning fixes: https://github.com/nathanchance/marlin/commits/76449b487e33ff90720258f39d347ba02a973e78 |
|
aha, https://android-review.googlesource.com/c/kernel/common/+/654139/1#message-cb1faaca844f8af9f7f60cec93128088c50a48a8 is proof @gregkh said he'll take fixes. I wonder if he can just pull from chromium's remote? |
|
Should we check with mka@ what happened ? The last exchange in the android review seemed to suggest that he sent a list of patches to Greg, but it seems that they didn't make it into LTS (?). |
|
heh, I just emailed @mkaehlcke to check. 🇿🇲 |
|
On Fri, Nov 09, 2018 at 09:18:35PM -0800, Guenter Roeck wrote:
Should we check with mka@ what happened ? The last exchange in the android review seemed to suggest that he sent a list of patches to Greh, but it seems that they didn't make it into LTS (?).
I took a ton of patches for LTS kernels for clang, what did I miss?
Following up with a simple "hey, these are still lacking" would be most
appreciated given that I don't run clang myself on those kernels.
thanks,
greg k-h
|
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
|
The following five commits allow an arm32 defconfig build to complete and boot successfully on 4.14.81: ClangBuiltLinux/linux@10d8713 https://travis-ci.com/nathanchance/continuous-integration/jobs/158337755 I also included this commit otherwise there are tons of assembler warnings about unified syntax: ClangBuiltLinux/linux@75fea30 ClangBuiltLinux/linux@41f1c48 is needed for 4.19 as well. |
commit 81b45683487a ("compiler.h: give up __compiletime_assert_fallback()")
is needed because travis kills the job otherwise due to log spew. See
build 271.
> The job exceeded the maximum log length, and has been terminated.
The proper fix is to send the backport, TODO.
commit 81b45683487a ("compiler.h: give up __compiletime_assert_fallback()")
is needed because travis kills the job otherwise due to log spew. See
build 271.
> The job exceeded the maximum log length, and has been terminated.
The proper fix is to send the backport, TODO.
Issue ClangBuiltLinux#35. Presubmit run: https://travis-ci.com/nickdesaulniers/continuous-integration/builds/91934518 Need to add more to clean up warnings.
|
Forgot about your latest comment @nathanchance . I will tackle those and 4.4 arm32 hopefully later this week. |
We first shipped a clang built 4.4 kernel on Pixel 2 (though we did have a patchset for 3.18 working on Pixel 1). Now that we're testing torvalds/linux and -next, it would be good to add support for LTS branches (but only back to 4.4).
I'm thinking of moving the switch statements to some kind of hierarchical config or data structure. I think it that way, it will make adding more targets easier in the future.
@tom-gall sent me some configs based off these LTS branches, but I think having the defconfigs for these LTS branches being tested is a good first step towards that goal.
The text was updated successfully, but these errors were encountered: