From: Philip Li <philip.li@intel.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: <julie.du@intel.com>, 0day robot <lkp@intel.com>,
<kdevops@lists.linux.dev>, Joel Granados <j.granados@samsung.com>,
"Daniel Gomez" <da.gomez@samsung.com>,
Christian Brauner <brauner@kernel.org>,
"Hugh Dickins" <hughd@google.com>,
Gustavo Padovan <gustavo.padovan@collabora.com>,
<linux-modules@vger.kernel.org>,
Kees Cook <keescook@chromium.org>,
"Linux FS Devel" <linux-fsdevel@vger.kernel.org>
Subject: Re: Automation with 0-day & kdevops
Date: Sun, 25 Feb 2024 19:28:00 +0800 [thread overview]
Message-ID: <ZdskQE0iwFXpPhGw@rli9-mobl> (raw)
In-Reply-To: <CAB=NE6VRZFn+jxmxADGb3j7fLzBG9rAJ-9RCddEwz0HtwvtHxg@mail.gmail.com>
On Fri, Feb 23, 2024 at 07:44:12AM -0800, Luis Chamberlain wrote:
> Dear 0-day developers,
>
> kdevops [0] has evolved over the years now to a full automation suite
> for kernel development and testing. As for the later aspects of it, we
> use it to enable complicated subsystem tests such as filesystems
> testing. Our automated filesystem coverage has been rather reduced
> given the complexity, and so one of its goals was to tackle this. It
> also has support to automate testing complex subsystems involving
> custom non-upstream yet for things like qemu as well.
>
> While long term we'd like to aim towards automating most of the things
> tested under kdevops, it makes sense to start slow with a few simpler
> targets. Since kdevops supports kselftests as well, my recommendation
> is we start with a few selftests for components we have kernel
> maintainers willing to help with either review or help tune up. The
> same applies to filesystems. While we have support to test most
> popular filesystems it makes sense to start with something simple.
>
> To this end I'd like to see if we can collaborate with 0-day so enable
> automation of testing for the following components, the first 3 of
> which I help maintain:
>
> With kdevops using its kernel selftests support:
>
> * Linux kernel modules: using kernel selftests and userspace kmod tests
> * Linux firmware loader: firmware selftests
> * Linux sysctl
>
> As for filesystems I'd like to start with tmpfs as we have a developer
> who already has a good baseline for it, and is helping to fix some
> fstests bugs found, Daniel Gomez. We also have created different
> target profiles to test tmpfs for the different mount options it
> supports.
>
> What would this collaboration consist of? Using 0-day's automated to
> git clone kdevops, spawn some resouces and run a series of make
> commands. If git diff returns non-empty we have a new failure.
Thanks Luis, we are glad to collaborate on this. We will learn the detail of
kdevops that the website contains a lot of useful materials. And we will update
our progress to you next month for the questions and next steps.
Thanks
>
> [0] https://github.com/linux-kdevops/kdevops
>
> Luis
>
next prev parent reply other threads:[~2024-02-25 11:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 15:44 Automation with 0-day & kdevops Luis Chamberlain
2024-02-25 11:28 ` Philip Li [this message]
2024-03-15 18:25 ` Luis Chamberlain
2024-03-19 1:38 ` Philip Li
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=ZdskQE0iwFXpPhGw@rli9-mobl \
--to=philip.li@intel.com \
--cc=brauner@kernel.org \
--cc=da.gomez@samsung.com \
--cc=gustavo.padovan@collabora.com \
--cc=hughd@google.com \
--cc=j.granados@samsung.com \
--cc=julie.du@intel.com \
--cc=kdevops@lists.linux.dev \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mcgrof@kernel.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