kernel tree support matrix for Clang

kernel tree support matrix for Clang

[ndesaulniers]

Following up with Matt from this past week's meeting.

For building kernels with Clang, I'm running a bare bones CI I setup
on TravisCI; I would like to transition all of this to kernelCI.
Because we're using TravisCI's free tier, the build boxes are dual
core and builds timeout after 50 minutes.  This causes us to rely
heavily on ccache (last night's builds all were cold because of the
nightly compiler uprev; build 792 has some hot cache timings), and
limits our coverage to basically defconfigs.

In terms of what trees/branches/ISAs are important, let's look at last
night's build as an example:
https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/116089229

Currently 40 targets.  They're not partitioned in the UI, but here's
how I view them:
794.1-794.7 are builds of mainline (torvalds/linux) various archs and
LLD enabled if supported
794.8-794.14 are builds of the master branch of linux-next tree.
794.15-794.18 are builds of the 4.19.y branch of the stable tree.
794.19-794.22 are builds of the 4.14.y branch of the stable tree.
794.23-794.25 are builds of the 4.9.y branch of the stable tree.
794.26-794.27 are builds of the 4.4.y branch of the stable tree.
794.28-794.33 are builds of various branches of the android-common tree.
794.34-794.40 are builds of mainline with the latest released version
of clang, clang-8. All of the above use ToT clang from the Clang
Debian package maintainer in a docker image we build nightly.

linux-next coverage is important to us for observing regressions ASAP
and hopefully before they hit mainline.
mainline coverage is important to us so that clang "just works" for
anyone who clones linux and tries clang.
stable coverage is important to us because Android and CrOS base their
device kernels off of stable.
android-common trees are downstream of the stable trees, and are
important that we don't regress them.
clang-8 tests are important to us so that users who don't build their
own compiler can use a released version of clang and it "just works".

Today KernelCI is covering builds of linux-next with Clang, which is a
great first step.  I think the above list of trees & branches listed
above for the reasons above are good next steps for KernelCI coverage.

What do you all think?
-- 
Thanks,
~Nick Desaulniers

Re: kernel tree support matrix for Clang

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

On Wed, Jun 19, 2019 at 11:04:34AM -0700, Nick Desaulniers via Groups.Io wrote:

> https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/116089229
> 
> Currently 40 targets.  They're not partitioned in the UI, but here's
> how I view them:

These appear to mostly be defconfig builds?

> Today KernelCI is covering builds of linux-next with Clang, which is a
> great first step.  I think the above list of trees & branches listed
> above for the reasons above are good next steps for KernelCI coverage.

> What do you all think?

The last time we talked about it the plan was to turn clang builds on
for mainline just as soon as the last few patches for making that build
land so that should be after the merge window.

For the stables I did see in at least v4.4 what looked like new
warnings, I'm guessing Greg would take fixes for them but it's probably
better to do do that before enabling anything.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: kernel tree support matrix for Clang

[Nick Desaulniers]

On Wed, Jun 19, 2019 at 11:57 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Jun 19, 2019 at 11:04:34AM -0700, Nick Desaulniers via Groups.Io wrote:
>
> > and
> > limits our coverage to basically defconfigs.
>
> These appear to mostly be defconfig builds?

Yes, there are some hacks with scripts/config to enable a few more
things (kselftests), but allyesconfig blows through our allotted 50
minutes on the free tier 2 core boxes.

> > Today KernelCI is covering builds of linux-next with Clang, which is a
> > great first step.  I think the above list of trees & branches listed
> > above for the reasons above are good next steps for KernelCI coverage.
>
> > What do you all think?
>
> The last time we talked about it the plan was to turn clang builds on
> for mainline just as soon as the last few patches for making that build
> land so that should be after the merge window.

Which merge window? 5.1 or 5.2?

> For the stables I did see in at least v4.4 what looked like new
> warnings, I'm guessing Greg would take fixes for them but it's probably
> better to do do that before enabling anything.

GKH has been accepting patches for enabling Clang support.  Nathan
Chancellor, Matthias Kaehlcke, and I have been sending backports for
Clang support.
-- 
Thanks,
~Nick Desaulniers

Re: kernel tree support matrix for Clang

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Wed, Jun 19, 2019 at 02:12:53PM -0700, Nick Desaulniers wrote:
> On Wed, Jun 19, 2019 at 11:57 AM Mark Brown <broonie@kernel.org> wrote:

> > The last time we talked about it the plan was to turn clang builds on
> > for mainline just as soon as the last few patches for making that build
> > land so that should be after the merge window.

> Which merge window? 5.1 or 5.2?

I can't remember off the top of my head; in any case v5.1 is released
so the v5.2 merge window has passed if everything is in there.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: kernel tree support matrix for Clang

[Matt Hart]

Hi all,

Was there an agreement on what trees/branches to consider adding to kernelci?
If there are any that are expected to be noisy or fail I can try them
out on staging first.

On Thu, 20 Jun 2019 at 12:30, Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Jun 19, 2019 at 02:12:53PM -0700, Nick Desaulniers wrote:
> > On Wed, Jun 19, 2019 at 11:57 AM Mark Brown <broonie@kernel.org> wrote:
>
> > > The last time we talked about it the plan was to turn clang builds on
> > > for mainline just as soon as the last few patches for making that build
> > > land so that should be after the merge window.
>
> > Which merge window? 5.1 or 5.2?
>
> I can't remember off the top of my head; in any case v5.1 is released
> so the v5.2 merge window has passed if everything is in there.

Re: kernel tree support matrix for Clang

[Nick Desaulniers]

On Tue, Jun 25, 2019 at 6:55 AM Matt Hart <matthew.hart@linaro.org> wrote:
>
> Hi all,
>
> Was there an agreement on what trees/branches to consider adding to kernelci?
> If there are any that are expected to be noisy or fail I can try them
> out on staging first.

Hi Matt,
I just filed:
- https://github.com/kernelci/kernelci-core/issues/103: [clang]
additional trees/branches
- https://github.com/kernelci/kernelci-core/issues/104: [clang] enable lld
- https://github.com/kernelci/kernelci-core/issues/105: [clang]
additional arches

I think those would greatly expand coverage for the important cases.

Probably worthwhile to test each on staging, but I expect defconfigs
to be much cleaner (I'm worried about allyesconfig builds on stable
trees).
-- 
Thanks,
~Nick Desaulniers

Re: kernel tree support matrix for Clang

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

On Tue, Jun 25, 2019 at 12:45:58PM -0700, Nick Desaulniers via Groups.Io wrote:

> Hi Matt,
> I just filed:
> - https://github.com/kernelci/kernelci-core/issues/103: [clang]
> additional trees/branches
> - https://github.com/kernelci/kernelci-core/issues/104: [clang] enable lld
> - https://github.com/kernelci/kernelci-core/issues/105: [clang]
> additional arches

I replied on the tickets, note that : is a valid character in a URL so
the way you've written things there makes it slightly annoying to
cut'n'paste the URLs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]