linux-kernel - kselftest tree on kernelci.org

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 2 Feb 2022 13:32:31 +0000
From:   Guillaume Tucker <guillaume.tucker@...labora.com>
To:     Shuah Khan <shuah@...nel.org>
Cc:     linux-kselftest@...r.kernel.org,
        "kernelci@...ups.io" <kernelci@...ups.io>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Collabora Kernel ML <kernel@...labora.com>
Subject: kselftest tree on kernelci.org

Hi Shuah,

I've made this PR to start monitoring the "fixes" branch from the
kselftest tree on kernelci.org:

  https://github.com/kernelci/kernelci-core/pull/998

While kselftest changes eventually land in linux-next, monitoring
your tree directly means we can test it earlier and potentially
enable more build variants or experimental tests.  Since
kernelci.org also builds and runs some kselftests we're regularly
finding issues and people are sending fixes for them.  See this
recent story for example:

  https://twitter.com/kernelci/status/1488831497259921409

Keeping an eye on kselftest patches with kernelci.org means we
can verify that fixes do what they're supposed to do with a much
larger test coverage than what individual developers can do.
We've been applying kselftest fixes on a branch managed by
kernelci.org to verify them in the past, but having the actual
kselftest tree part of the workflow would seem much better.

There are several branches in your tree, while "fixes" seemed
like the most useful one to pick I see there is also a "kernelci"
branch too but it hasn't been updated for a while, reviving it
could give you the possibility to test patches through
kernelci.org before applying them on other branches that get
pulled into linux-next and mainline.

Many things could potentially be done with arbitrary builds and
tests etc.  These are some initial suggestions.  How does this
sound?

Best wishes,
Guillaume