On Mon, 2018-11-26 at 17:41 -0800, Brendan Higgins wrote:
On Fri, Nov 23, 2018 at 9:15 PM Knut Omang <knut.omang@xxxxxxxxxx> wrote:
<snip>
On Tue, 2018-10-23 at 16:57 -0700, Brendan Higgins wrote:
Brendan, I regret you weren't at this year's testing and fuzzing workshop at
LPC last week so we could have continued our discussions from last year there!
Likewise! Unfortunately, I could not make it. So it goes.
I hope we can work on this for a while longer before anything gets merged.
Maybe it can be topic for a longer session in a future test related workshop?
I don't see why we cannot just discuss it here as we are already
doing.
Yes, as long as we are not wasting all the Cc:'ed people's valuable time.
Besides, you are mostly interested in out of tree testing,
right? I don't see how this precludes anything that you are trying to
do with KTF.
Both approaches provide assertion macros for running tests inside the kernel,
I doubt the kernel community would like to see yet two such sets of macros,
with differing syntax merged. One of the good reasons to have a *framework*
is that it is widely used and understood, so that people coming from one part of the
kernel can easily run, understand and relate to selected tests from another part.
The goal with KTF is to allow this for any kernel, old or new, not just kernels
built specifically for testing purposes. We felt that providing it as a separate git
module (still open source, for anyone to contribute to) is a more efficient approach
until we have more examples and experience with using it in different parts
of the kernel. We can definitely post the kernel side of KTF as a patch series fairly soon
if the community wants us to. Except for hybrid tests, the ktf.ko module works fine
independently of any user side support, just using the debugfs interface to run and
examine tests.
I think there are good uses cases for having the ability to maintain a
single source for tests that can be run against multiple kernels,
also distro kernels that the test framework cannot expect to be able to modify,
except from using the module interfaces.
And there are good arguments for having (at least parts of)
the test framework easily available within the kernel under test.