[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjcJxypxUOSF-jc=SQKT1CrOoTMyT7soYzbvK3965JmCA@mail.gmail.com>
Date: Sun, 6 Oct 2019 10:18:11 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Theodore Y. Ts'o" <tytso@....edu>
Cc: Brendan Higgins <brendanhiggins@...gle.com>,
shuah <shuah@...nel.org>, Frank Rowand <frowand.list@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Kees Cook <keescook@...gle.com>,
Kieran Bingham <kieran.bingham@...asonboard.com>,
Luis Chamberlain <mcgrof@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Rob Herring <robh@...nel.org>, Stephen Boyd <sboyd@...nel.org>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
devicetree <devicetree@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
kunit-dev@...glegroups.com,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
linux-nvdimm <linux-nvdimm@...ts.01.org>,
linux-um@...ts.infradead.org,
Sasha Levin <Alexander.Levin@...rosoft.com>,
"Bird, Timothy" <Tim.Bird@...y.com>,
Amir Goldstein <amir73il@...il.com>,
Dan Carpenter <dan.carpenter@...cle.com>,
Daniel Vetter <daniel@...ll.ch>, Jeff Dike <jdike@...toit.com>,
Joel Stanley <joel@....id.au>,
Julia Lawall <julia.lawall@...6.fr>,
Kevin Hilman <khilman@...libre.com>,
Knut Omang <knut.omang@...cle.com>,
Logan Gunthorpe <logang@...tatee.com>,
Michael Ellerman <mpe@...erman.id.au>,
Petr Mladek <pmladek@...e.com>,
Randy Dunlap <rdunlap@...radead.org>,
Richard Weinberger <richard@....at>,
David Rientjes <rientjes@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>, wfg@...ux.intel.com
Subject: Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit
testing framework
On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o <tytso@....edu> wrote:
>
> Well, one thing we *can* do is if (a) if we can create a kselftest
> branch which we know is stable and won't change, and (b) we can get
> assurances that Linus *will* accept that branch during the next merge
> window, those subsystems which want to use kself test can simply pull
> it into their tree.
Yes.
At the same time, I don't think it needs to be even that fancy. Even
if it's not a stable branch that gets shared between different
developers, it would be good to just have people do a "let's try this"
throw-away branch to use the kunit functionality and verify that
"yeah, this is fairly convenient for ext4".
It doesn't have to be merged in that form, but just confirmation that
the infrastructure is helpful before it gets merged would be good.
Linus
Powered by blists - more mailing lists