Re: [Automated-testing] Plumbers Testing MC potential topic: specialised toolchains

[Guillaume Tucker <gtucker@gtucker.io>]

On 18/09/2024 09:33, Guillaume Tucker wrote:
> 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.

Well, we're now more than a week after but I got some extras with
actual container images and a blog post with all the details:

    https://gtucker.io/posts/2024-09-30-korg-containers/

In a nutshell, this went down rather well at Plumbers.  I think
there are still a few critical points to address before bringing
this up as actual RFC kernel patches but let's see how this goes.

Many thanks once again to the Toolchain Track organizers and
Nathan for the feedback.

Best wishes,
Guillaume