From: Kees Cook <keescook@chromium.org>
To: "Bird, Tim" <Tim.Bird@sony.com>
Cc: Brendan Higgins <brendanhiggins@google.com>,
"shuah@kernel.org" <shuah@kernel.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
David Gow <davidgow@google.com>
Subject: Re: RFC - kernel selftest result documentation (KTAP)
Date: Tue, 16 Jun 2020 20:36:06 -0700 [thread overview]
Message-ID: <202006162032.9BF6F8F4E@keescook> (raw)
In-Reply-To: <CY4PR13MB1175DCC4066FC0839A6B2E84FD9A0@CY4PR13MB1175.namprd13.prod.outlook.com>
On Wed, Jun 17, 2020 at 02:30:45AM +0000, Bird, Tim wrote:
> Agreed. You only need machine-parsable data if you expect the CI
> system to do something more with the data than just present it.
> What that would be, that would be common for all tests (or at least
> many test), is unclear. Maybe there are patterns in the diagnostic
> data that could lead to higher-level analysis, or even automated
> fixes, that don't become apparent if the data is unstructured. But
> it's hard to know until you have lots of data. I think just getting
> the other things consistent is a good priority right now.
Yeah. I think the main place for this is performance analysis, but I
think that's a separate system entirely. TAP is really strictly yes/no,
where as performance analysis a whole other thing. The only other thing
I can think of is some kind of feature analysis, but that would be built
out of the standard yes/no output. i.e. if I create a test that checks
for specific security mitigation features (*cough*LKDTM*cough*), having
a dashboard that shows features down one axis and architectures and/or
kernel versions on other axes, then I get a pretty picture. But it's
still being built out of the yes/no info.
*shrug*
I think diagnostic should be expressly non-machine-oriented.
--
Kees Cook
next prev parent reply other threads:[~2020-06-17 3:36 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 18:11 RFC - kernel selftest result documentation (KTAP) Bird, Tim
2020-06-13 5:07 ` David Gow
2020-06-15 17:34 ` Bird, Tim
2020-06-16 20:03 ` Brendan Higgins
2020-06-16 20:37 ` Bird, Tim
2020-06-17 0:02 ` Kees Cook
2020-06-19 19:32 ` Brendan Higgins
2020-06-19 18:17 ` Frank Rowand
2020-06-14 18:17 ` Kees Cook
2020-06-15 17:45 ` Bird, Tim
2020-06-15 18:44 ` Kees Cook
2020-06-14 18:39 ` Kees Cook
2020-06-15 19:07 ` Bird, Tim
2020-06-16 12:08 ` Paolo Bonzini
2020-06-16 16:42 ` Bird, Tim
2020-06-16 19:44 ` Brendan Higgins
2020-06-16 20:30 ` Bird, Tim
2020-06-16 23:58 ` Kees Cook
2020-06-19 18:47 ` Frank Rowand
2020-06-19 19:11 ` Kees Cook
2020-06-19 22:58 ` Paolo Bonzini
2020-06-20 14:51 ` Frank Rowand
2020-06-19 18:33 ` Frank Rowand
2020-06-19 17:58 ` Frank Rowand
2020-06-20 6:44 ` David Gow
2020-06-20 15:03 ` Frank Rowand
2020-06-23 2:58 ` David Gow
2020-06-16 23:52 ` Kees Cook
2020-06-19 18:52 ` Frank Rowand
2020-06-19 19:50 ` Brendan Higgins
2020-06-19 19:49 ` Frank Rowand
2020-06-16 20:48 ` Brendan Higgins
2020-06-16 21:16 ` Bird, Tim
2020-06-16 21:19 ` Bird, Tim
2020-06-17 0:06 ` Kees Cook
2020-06-17 2:30 ` Bird, Tim
2020-06-17 3:36 ` Kees Cook [this message]
2020-06-17 4:05 ` David Gow
2020-06-19 19:44 ` Brendan Higgins
2020-06-19 20:19 ` Frank Rowand
2020-06-19 23:47 ` Bird, Tim
2020-06-19 19:39 ` Brendan Higgins
2020-06-19 17:13 ` Frank Rowand
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=202006162032.9BF6F8F4E@keescook \
--to=keescook@chromium.org \
--cc=Tim.Bird@sony.com \
--cc=brendanhiggins@google.com \
--cc=davidgow@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=shuah@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;
as well as URLs for NNTP newsgroup(s).