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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.