mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Knut Omang <knut.omang@oracle.com>
To: Dhaval Giani <dhaval.giani@gmail.com>,
	Sasha Levin <alexander.levin@microsoft.com>,
	shuah <shuah@kernel.org>, Kevin Hilman <khilman@baylibre.com>,
	Tim Bird <tbird20d@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	"Carpenter,Dan" <dan.carpenter@oracle.com>,
	willy@infradead.org, gustavo.padovan@collabora.co.uk,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: Linux Testing Microconference at LPC
Date: Tue, 23 Apr 2019 10:37:51 +0200	[thread overview]
Message-ID: <f08575cfa7aae2c0d156ebbde75d7f6d8baefedf.camel@oracle.com> (raw)
In-Reply-To: <CAPhKKr_uVTFAzne0QkZFUGfb8RxQdVFx41G9kXRY7sFN-=pZ6w@mail.gmail.com>

Hi,

On Thu, 2019-04-11 at 10:37 -0700, Dhaval Giani wrote:
> Hi Folks,
> 
> This is a call for participation for the Linux Testing microconference
> at LPC this year.
> 
> For those who were at LPC last year, as the closing panel mentioned,
> testing is probably the next big push needed to improve quality. From
> getting more selftests in, to regression testing to ensure we don't
> break realtime as more of PREEMPT_RT comes in, to more stable distros,
> we need more testing around the kernel.
> 
> We have talked about different efforts around testing, such as fuzzing
> (using syzkaller and trinity), automating fuzzing with syzbot, 0day
> testing, test frameworks such as ktests, smatch to find bugs in the
> past. We want to push this discussion further this year and are
> interested in hearing from you what you want to talk about, and where
> kernel testing needs to go next.
> 
> Please let us know what topics you believe should be a part of the
> micro conference this year.

I'd like to propose another topic on unit test framework 
support in the kernel:

From the initial reactions and interest I have seen wrt. KTF 
(http://heim.ifi.uio.no/~knuto/ktf/, https://github.com/oracle/ktf) 
and the discussions on LKML around KUnit (https://lkml.org/lkml/2018/11/29/82), 
it seems there's a general belief that some form of unit test framework 
like these can be a good addition to the tools and infrastructure already available
in the kernel.

It seems however that different people have different notions about what 
and how such a framework should ideally look, and what features belong there.
I'd like to see if we can bring that discussion forward by focusing on 
some of these items, where people seem to have quite differing views
depending on where they come from. Here is a non extensive list of 
some topics that seems to pop up when this gets discussed:

  - "Purity" of unit testing - what constitutes a "unit" in the kernel?
  - Testing kernel code - user space vs kernel space? (both useful)
  - Immediate development/debugging requirements vs longer term needs
  - Driver/hardware interaction testing?
  - "Neat"-factor
  - ease of use
  - Network testing (more than 1 kernel involved)
  ...

I'd like to make a short intro into this, and hopefully we can have some 
good exchange based on that. 

[While our contribution (KTF) is currently available on Github, 
at that point in time I plan for us to have submitted a version 
of it to the LKML as well]

Thanks,
Knut


  parent reply	other threads:[~2019-04-23  8:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 17:37 Dhaval Giani
2019-04-18 10:22 ` Gustavo Padovan
2019-04-18 13:26   ` Steven Rostedt
2019-04-22  7:12     ` Guillaume Tucker
2019-04-23  8:37 ` Knut Omang [this message]
2019-04-23 10:22 ` Mark Rutland
2019-05-12  0:40   ` Andrea Parri
2019-05-22 15:52     ` Dmitry Vyukov
2019-05-23 14:03       ` Paul E. McKenney
2019-04-25 13:37 ` Veronika Kabatova
2019-04-26 21:02   ` Tim Bird
2019-05-16  0:39     ` Sasha Levin
2019-05-16  0:51       ` Tim.Bird
2019-05-22 16:04         ` Dmitry Vyukov
2019-05-22 16:07           ` Dhaval Giani
2019-05-22 15:48     ` Dmitry Vyukov
2019-05-23  0:07       ` Tim.Bird
2019-05-23  6:49         ` Dmitry Vyukov
2019-05-15 22:44 ` shuah
2019-05-15 23:19   ` Brendan Higgins
2019-05-16  0:36   ` Sasha Levin
2019-05-22 21:02     ` Brendan Higgins
2019-05-23  0:58       ` Steven Rostedt
2019-05-23  1:00         ` Steven Rostedt
2019-05-23  4:54       ` Knut Omang
2019-06-03  8:59         ` Brendan Higgins
2019-05-22 16:11 ` Dhaval Giani
2019-06-10 11:21   ` Douglas Raillard

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=f08575cfa7aae2c0d156ebbde75d7f6d8baefedf.camel@oracle.com \
    --to=knut.omang@oracle.com \
    --cc=alexander.levin@microsoft.com \
    --cc=dan.carpenter@oracle.com \
    --cc=dhaval.giani@gmail.com \
    --cc=dvyukov@google.com \
    --cc=gustavo.padovan@collabora.co.uk \
    --cc=khilman@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=shuah@kernel.org \
    --cc=tbird20d@gmail.com \
    --cc=willy@infradead.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

Powered by JetHome