KernelCI discussions
 help / color / mirror / Atom feed
From: "Dan Rue" <dan.rue@linaro.org>
To: Guillaume Tucker <guillaume.tucker@collabora.com>
Cc: tuxbuild <tuxbuild@linaro.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	kernelci@groups.io
Subject: Re: TuxBuild Now Supports Clang 11 and 5 new architectures
Date: Mon, 23 Nov 2020 11:05:13 -0600	[thread overview]
Message-ID: <20201123170513.mdfs53skfdcux7jm@jug> (raw)
In-Reply-To: <b455831c-1205-551f-6bb2-6bb33b750d17@collabora.com>

On Thu, Nov 19, 2020 at 09:13:41AM +0000, Guillaume Tucker wrote:
> Hi Dan,

Hi Guillaume!

> 
> On 17/11/2020 21:41, Dan Rue wrote:
> > Cheers!
> > 
> > Today we've deployed support for clang-11, and we dropped support for clang 8 and 9 based on user feedback.
> > 
> > In addition, we have added the following architectures with gcc 8, 9, and 10:
> > - s390
> > - powerpc
> > - sparc
> > - hppa
> > - sh
> > 
> > TuxBuild's full support matrix is as follows:
> > 
> >          arc arm arm64 hppa i386 mips powerpc riscv s390 sh  sparc x86_64
> > clang-10 no  yes yes   no   yes  yes  no      yes   no   no  no    yes
> > clang-11 no  yes yes   no   yes  yes  no      yes   no   no  no    yes
> 
> Out of interest, are there builds produced with tuxbuild for all
> the supported configurations that can be downloaded with a build
> log?

I don't think there's anything published, but Antonio might have
something related to the container tests that are done in tuxmake before
publishing new containers.

> 
> I've just been working on building riscv with Clang for KernelCI
> and there are quite a few issues, we've dropped clang-10 as it's
> actually broken.  So I wonder if you define "supported" solely by
> having a Docker image and the ability to start a build, or if
> it's required to actually complete a kernel build?
> 
> See related discussion about riscv here:
> 
>   https://github.com/kernelci/kernelci-core/pull/534

If there is a legitimate problem in the kernel sources or in a toolchain
implementation, the tuxmake would be expected to fail, and tuxmake
shouldn't work around things that are broken.

If tuxmake is doing the wrong thing, then it's a bug that we should fix.

If a combination might work but currently doesn't, tuxmake can support
it. If it will never work, we won't bother.

`tuxmake -r podman -t riscv -t clang-10` works for me on v5.10-rc5.
Here's the tuxbuild of the same, with logs and such:
https://builds.tuxbuild.com/1khN9GYmp4AKa1g6m4MwM7yhgnE/

> 
> 
> > gcc-10   no  yes yes   yes  yes  yes  yes     yes   yes  yes yes   yes
> > gcc-8    yes yes yes   yes  yes  yes  yes     yes   yes  yes yes   yes
> > gcc-9    yes yes yes   yes  yes  yes  yes     yes   yes  yes yes   yes
> > 
> > We're still updating the tuxbuild documentation, but the new toolchains and architectures are available immediately without a tuxbuild update (the argument validation is all done server-side).
> > 
> > Now that we have TuxMake integration which is enabling these new features, we would like to add tuxmake build reproducers to tuxbuild. A build reproducer is a simple one-line shell script provided alongside the other tuxbuild artifacts, which contain the tuxmake command-line invocation to perform the same build locally. For example:
> > 
> >     $ cat tuxmake_reproducer.sh
> >     tuxmake --runtime docker --image docker.io/tuxmake/arm64_clang-11 <http://docker.io/tuxmake/arm64_clang-11> --target-arch arm64 --kconfig defconfig --kconfig-add "CONFIG_KASAN=y" --toolchain clang-11
> 
> That's nice but I believe it would be easier to adopt if the
> syntax was simpler.  For example:
> 
>   tuxmake --runtime docker --target-arch arm64 --kconfig defconfig --kconfig-add "CONFIG_KASAN=y" --toolchain clang-11
> 
> or if you really want to keep the docker image mentioned to
> ensure reproducibility:
> 
>   tuxmake --runtime docker --image docker.io/tuxmake/arm64_clang-11 --kconfig defconfig --kconfig-add "CONFIG_KASAN=y"
> 
> I can see why you would want to define all the parameters
> explicitly, but it seems like there's some repetition there.  If
> the docker image is already arch-specific, then do you also need
> to specify the arch as a separate parameter?

You're right, --image in the above example was superfluous. We were
struggling to decide how granular to be with reproducers because you can
be as simple as:

    tuxmake --runtime docker --target-arch x86_64 --kconfig defconfig --toolchain gcc

And as "correct" as e.g.:

    tuxmake --image docker.io/tuxmake/x86_64_gcc@sha256:f8218cbfad8ecf6628fc44db864a402070feb87ff43a880e1409649172d4bc8c -r docker --target-arch x86_64 --kconfig tinyconfig --toolchain gcc -e "KBUILD_BUILD_TIMESTAMP='Tue May 26 16:16:14 2020 -0500'" -e "KBUILD_BUILD_USER=tuxmake" -e "KBUILD_BUILD_HOST=tuxmake"

The latter provides (at least potentially) an actual reproducible build,
but the former is simpler and usually sufficient.

We decided to favor simplicity and all tuxbuilds now publish a
tuxbuild_reproducer.sh and tuxmake_reproducer.sh which consists of the
simple version of the command.

For example in the risc5/clang-10 build from above, we see the following
two reproducers now:

tuxbuild_reproducer.sh:
https://builds.tuxbuild.com/1khN9GYmp4AKa1g6m4MwM7yhgnE/tuxbuild_reproducer.sh

    #!/bin/sh

    tuxbuild build --git-repo https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git --git-sha 418baf2c28f3473039f2f7377760bd8f6897ae18 --target-arch riscv --toolchain clang-10 --kconfig defconfig


tuxmake_reproducer.sh:
https://builds.tuxbuild.com/1khN9GYmp4AKa1g6m4MwM7yhgnE/tuxmake_reproducer.sh

    #!/bin/sh

    tuxmake --runtime docker --target-arch riscv --toolchain clang-10 --kconfig defconfig


Hope that helps!
Dan

> 
> Best wishes,
> Guillaume
> 
> > As a kernel developer, would you appreciate receiving such a command as a part of a build discussion on a mailing list?
> > 
> > Would you send something like that to your colleagues?
> > 
> > Do you find the concept of a local reproducer helpful?
> > 
> > Thanks again to everyone using and supporting TuxBuild and TuxMake - we see you and we appreciate you,
> > 
> > Dan
> > 
> > p.s. Did you know that it's possible to perform actual reproducible builds with tuxmake? It's true. Try it for yourself, and see if your bzImage sha256sum matches:
> > 
> >     $ git describe
> >     v5.10-rc4
> >     $ tuxmake --image docker.io/tuxmake/x86_64_gcc@sha256:f8218cbfad8ecf6628fc44db864a402070feb87ff43a880e1409649172d4bc8c <http://docker.io/tuxmake/x86_64_gcc@sha256:f8218cbfad8ecf6628fc44db864a402070feb87ff43a880e1409649172d4bc8c> -r docker -k tinyconfig -e "KBUILD_BUILD_TIMESTAMP='Tue May 26 16:16:14 2020 -0500'" -e "KBUILD_BUILD_USER=tuxmake" -e "KBUILD_BUILD_HOST=tuxmake"
> >     ...
> >     $ sha256sum /home/drue/.cache/tuxmake/builds/634/bzImage 
> >     5581ed4583fb4b9d76760ee329e248fe7281d7ea3b6ae0737efc7a6a4462affa  /home/drue/.cache/tuxmake/builds/634/bzImage
> > 
> > p.p.s. Did you know that tuxmake also supports podman? Just use -r podman instead of -r docker.
> 

-- 
Linaro LKFT
https://lkft.linaro.org

      reply	other threads:[~2020-11-23 17:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAGm4vTM-ozY8wSsuZhqCsz8qnrjaCRkmLnLJVkuYB6sVUaqnuQ@mail.gmail.com>
2020-11-19  9:13 ` TuxBuild Now Supports Clang 11 and 5 new architectures Guillaume Tucker
2020-11-23 17:05   ` Dan Rue [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201123170513.mdfs53skfdcux7jm@jug \
    --to=dan.rue@linaro.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=guillaume.tucker@collabora.com \
    --cc=kernelci@groups.io \
    --cc=tuxbuild@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox