From: Guillaume Tucker <gtucker@gtucker.io>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Miguel Ojeda <ojeda@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
llvm@lists.linux.dev, rust-for-linux@vger.kernel.org,
yurinnick@meta.com, bpf@vger.kernel.org,
Sasha Levin <sashal@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>,
automated-testing@lists.yoctoproject.org
Subject: Re: Plumbers Testing MC potential topic: specialised toolchains
Date: Wed, 18 Sep 2024 09:33:28 +0200 [thread overview]
Message-ID: <da705c5d-9263-46dc-993e-dffee25969a3@gtucker.io> (raw)
In-Reply-To: <e0b6e4b6-549a-43dc-bc76-3f8488cf5dd2@gtucker.io>
Hello,
On 14/07/2024 1:03 am, Guillaume Tucker wrote:
>>> very interested to hear whether people feel it would be
>>> beneficial to work towards a more exhaustive solution supported
>>> upstream: kernel.org Docker images or something close such as
>>> Dockerfiles in Git or another type of images with all the
>>> dependencies included. How does that sound?
>> A few thoughts around this:
>>
>> Having first party Dockerfiles could be useful but how would they be
>> used? Perhaps building a kernel in such a container could be plumbed
>> into Kbuild, such that the container manager could be invoked to build
>> the image if it does not exist then build the kernel in that image? This
>> might be a lofty idea but it would remove a lot of the friction of using
>> containers to build the kernel so that more people would adopt it?
> That's a great idea, and I think it's why having a live
> discussion at Plumbers would make sense as it's going to be
> harder to reach answers in a thread like this.
In fact I went ahead and made a small PoC for this as an experiment:
https://gitlab.com/gtucker/linux/-/commits/linux-6.7-make-container
>> Another aspect of this is discoverability. I think a big problem with a
>> project like TuxMake is that while it is developed for the kernel
>> community, it is not a first party project, so without word of mouth,
>> there is not a great way for other people to hear about it.
>>
>> I think it would be a good idea to try and solicit feedback from the
>> greater kernel community at large to ensure that whatever solution is
>> decided on will work for both testing systems and
>> developers/maintainers. I think that a first party solution for having a
>> consistent and easy to set up/work with build environment has been
>> needed for some time but unfortunately, I am not sure how much
>> discussion around this problem has happened directly with those folks.
> Yes, that was my intention here with this thread to start
> widening the audience with the upstream community. My
> understanding is that the issue hasn't been suitably framed to
> enable constructive discussion yet. I'll consider submitting a
> proposal for the Toolchain track next.
>
>>> [1]https://lpc.events/event/18/contributions/1665/
>>> [2]https://hub.docker.com/u/tuxmake
>>> [3]https://www.linaro.org/blog/tuxmake-building-linux-with-kernel-org-toolchains/
>> As an aside, consider using me as a point of contact for anything
>> ClangBuiltLinux related instead of Nick going forward, he has stepped
>> away to focus on LLVM libc for the immediate future.
> Noted, thank you.
>
>> Thanks a lot for bring up this topic. I think it is important to work on
>> and I look forward to talking through this at Plumbers.
> That would be greatly appreciated. Many thanks already for your
> insightful feedback.
The talk is happening today, slides are available:
https://lpc.events/event/18/contributions/1928/
I'll reply later this week with a follow-up from the live
discussions at Plumbers and maybe this will lead to some RFCs or
a few patches.
Thanks,
Guillaume
next prev parent reply other threads:[~2024-09-18 7:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-08 22:10 Plumbers Testing MC potential topic: specialised toolchains Guillaume Tucker
2024-07-08 22:22 ` [Automated-testing] " Richard Purdie
2024-07-08 23:07 ` Miguel Ojeda
2024-07-13 21:25 ` Guillaume Tucker
2024-07-09 5:30 ` Nathan Chancellor
2024-07-13 23:03 ` Guillaume Tucker
2024-09-18 7:33 ` Guillaume Tucker [this message]
[not found] ` <17F6464FBF21FF99.27464@lists.yoctoproject.org>
2024-09-30 20:07 ` [Automated-testing] " Guillaume Tucker
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=da705c5d-9263-46dc-993e-dffee25969a3@gtucker.io \
--to=gtucker@gtucker.io \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=automated-testing@lists.yoctoproject.org \
--cc=bpf@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=yurinnick@meta.com \
/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