archive mirror
 help / color / mirror / Atom feed
From: shuah <>
To: Brendan Higgins <>,
	Knut Omang <>
Cc: Luis Chamberlain <>,,,
	shuah <>
Subject: Re: Plan for hybrid testing
Date: Mon, 16 Sep 2019 10:20:28 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Brendan,

On 9/13/19 3:02 PM, Brendan Higgins wrote:
> Hey Knut and Shuah,
> Following up on our offline discussion on Wednesday night:

Awesome. Thanks for doing this.

> We decided that it would make sense for Knut to try to implement Hybrid
> Testing (testing that crosses the kernel userspace boundary) that he
> introduced here[1] on top of the existing KUnit infrastructure.
> We discussed several possible things in the kernel that Knut could test
> with the new Hybrid Testing feature as an initial example. Those were
> (in reverse order of expected difficulty):
> 1. RDS (Reliable Datagram Sockets) - We decided that, although this was
>     one of the more complicated subsystems to work with, it was probably
>     the best candidate for Knut to start with because it was in desperate
>     need of better testing, much of the testing would require crossing
>     the kernel userspace boundary to be effective, and Knut has access to
>     RDS (since he works at Oracle).
> 2. KMOD - Probably much simpler than RDS, and the maintainer, Luis
>     Chamberlain (CC'ed) would like to see better testing here, but
>     probably still not as good as RDS because it is in less dire need of
>     testing, collaboration on this would be more difficult, and Luis is
>     currently on an extended vacation. Luis and I had already been
>     discussing testing KMOD here[2].
> 3. IP over USB - Least desirable option, but still possible. More
>     complicated than KMOD, and not as easy to collaborate on as RDS.
> I don't really think we discussed how this would work. I remember that I
> mentioned that it would be easier if I sent out a patch that
> centralizes where KUnit tests are dispatched from in the kernel; I will
> try to get an RFC for that out, probably sometime next week. That should
> provide a pretty straightforward place for Knut to move his work on top
> of.

That will be awesome.

> The next question is what the userspace component of this should look
> like. To me it seems like we should probably have the kselftest test
> runner manage when the test gets run, and collecting and reporting the
> result of the test, but I think Knut has thought more about this than I,
> and Shuah is the kselftest maintainer, so I am guessing this will
> probably mostly be a discussion between the two of you.

Yes. This is what I have in mind.

> So I think we have a couple of TODOs between us:
> Brendan:
>   - Need to send out patch that provides a single place where all tests
>     are dispatched from.
> Knut:
>   - Start splitting out the hybrid test stuff from the rest of the RFC
>     you sent previously.
> Knut and Shuah:
>   - Start figuring out what the userspace component of this will look
>     like.

Once Knut decides which one of the above options he chooses and sends me
RFC patches, we can start discussing the details based on the RFC.

-- Shuah

  reply	other threads:[~2019-09-16 16:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-13 21:02 Plan for hybrid testing Brendan Higgins
2019-09-16 16:20 ` shuah [this message]
2019-10-14 10:42 ` Luis Chamberlain
2019-10-14 18:38   ` Knut Omang
2019-10-14 19:01     ` shuah
2019-10-16 10:52       ` Knut Omang
2019-10-16 13:08         ` Luis Chamberlain
2019-10-17 17:46           ` Knut Omang
2019-10-17 19:11             ` shuah
2019-10-18  9:47             ` Luis Chamberlain
2019-10-18 18:35               ` Brendan Higgins
2019-10-18 19:22                 ` Luis Chamberlain
2019-10-18 19:58                   ` Brendan Higgins
2019-10-19 18:44                     ` Luis Chamberlain
2019-10-18 21:42           ` shuah

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* 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).