[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <196cb1de31b.ef78ff442883955.7374847682594204868@collabora.com>
Date: Tue, 13 May 2025 16:27:35 -0300
From: Gustavo Padovan <gus@...labora.com>
To: "Luis Chamberlain" <mcgrof@...nel.org>
Cc: "Song Liu" <song@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kdevops" <kdevops@...ts.linux.dev>,
"Jim Zemlin" <jzemlin@...ux-foundation.org>,
"Konstantin Ryabitsev" <mricon@...nel.org>,
"Javier González" <javier.gonz@...sung.com>,
"Greg Marsden" <greg.marsden@...cle.com>, "Tso Ted" <tytso@....edu>,
"Alexei Starovoitov" <ast@...nel.org>,
"Daniel Borkmann" <daniel@...earbox.net>,
"kernelci lists.linux.dev" <kernelci@...ts.linux.dev>,
"Greg KH" <gregkh@...uxfoundation.org>,
"Jakub Kicinski" <kicinski@...a.com>, "sashal" <sashal@...nel.org>
Subject: Re: The future of kernel-patches-daemon - folding under LF?
Hello,
I missed this discussion, so sorrry for coming in late.
---- On Tue, 15 Apr 2025 14:47:49 -0300 Luis Chamberlain <mcgrof@...nel.org> wrote ---
> Song,
>
> We're starting to rely on kernel-patches-deamon (kpd in short) [0] for quite a
> bit of linux-kernel subsystems and have integrated it on kdevops for them [1]
> [2]. We already use it for the modules subsystem but even then that runs into
> hiccups every now and then and we just have to restart it. For smaller
> subsystems we've started to experiment with lei based patchwork solutions, we
> started with the firmware loader, and the hope was that if that works we could
> move on to memory management to leverage the automation of tests we have for
> xarray, maple tree, and vmas. The lei patchwork instance which kernel.org admins
> have helped us with works well, however kpd doesn't yet work with it [3], so we
> can't even get that off the ground yet. In the meantime, we've been instead
> relying on linux-next tags to test other subsystems like memory management so we
> avoid regressions that way, instead of testing patches while on the mailing
> list. But we do want to get to the point we can test things proactively for
> different subsystems.
>
> While we could look for alternatives I think we need to face the fact that we
> need more kpd love. I'm convinced that the only way to scale Linux kernel-ci
> work is by dividing and conquering and those can contribute to different
> components do so, and kpd fits well right in, but I think we need to start
> thinking about scaling it beyond just Meta. While we could just try to
> contribute to it to fix lingering bugs I've noted my first issue with it,
> requring CLA [4], and I don't think it makes sense to fork it from Meta. kpd the
> sort of specialized daemon that also can take time to learn and believe at this
> point it might make sense if kpd can be part of the LF covered toolbox we can
> get support for. Ie, make it an LF project and see if we can get more help with
> the sort of pipelines that fit both Meta and the kernel community.
If we are talking about folding under the LF, then KernelCI[0] is really the place for that.
Part of the project mission is to be an umbrella for different project around testing
and validation for the Linux kernel community. Not only that, but support the ecosystem
by driving the creation of common stardands that can facilitate the communication
between different test/CI systems across the community.
We really need to move towards a more aligned testing story across the board, so all
systems can expand the value they add
I am happy to chat more about this.
Best,
- Gus
[0] https://kernelci.org/
>
> Let me know your thoughts.
>
> [0] https://github.com/facebookincubator/kernel-patches-daemon
> [1] https://github.com/linux-kdevops/kdevops/blob/main/docs/kernel-ci/README.md
> [2] https://github.com/linux-kdevops/kdevops/blob/main/docs/kernel-ci/kernel-ci-kpd.md
> [3] https://lkml.kernel.org/r/CAB=NE6X5mJJmcXjEkHyE=2f1CCA5fDDEjMFH_aMArrhom2qO8Q@mail.gmail.com
> [4] https://github.com/facebookincubator/kernel-patches-daemon/issues/62
>
> Luis
>
Powered by blists - more mailing lists