From: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
To: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
Cc: brakmo-b10kYP2dOMg@public.gmane.org,
Petr Mladek <pmladek-IBi9RG/b67k@public.gmane.org>,
Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
dri-devel
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Sasha Levin
<Alexander.Levin-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>,
linux-kselftest-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Frank Rowand
<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-nvdimm
<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>,
Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org>,
Knut Omang <knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
Kieran Bingham
<kieran.bingham-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>,
Jeff Dike <jdike-OPE4K8JWMJJBDgjK7y7TUQ@public.gmane.org>,
Dan Carpenter
<dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, "Bird,
Timothy" <Tim.Bird-7U/KSKJipcs@public.gmane.org>,
Kees Cook <keescook-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
linux-um-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>,
Julia Lawall <julia.lawall-L2FTfq7BK8M@public.gmane.org>,
kunit-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
Greg KH
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
Linux
Subject: Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
Date: Thu, 21 Mar 2019 09:55:12 -0700 [thread overview]
Message-ID: <CAFd5g45LKU+SZAFzn3RNCoxhzum0NAr9t+UJ80SJDMc_FeKgBQ@mail.gmail.com> (raw)
In-Reply-To: <ce355f5c-189c-816c-cde4-fb4e816d44e7-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On Thu, Mar 21, 2019 at 8:56 AM Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org> wrote:
>
>
>
> On 2019-03-20 11:23 p.m., Knut Omang wrote:
> > Testing drivers, hardware and firmware within production kernels was the use
> > case that inspired KTF (Kernel Test Framework). Currently KTF is available as a
> > standalone git repository. That's been the most efficient form for us so far,
> > as we typically want tests to be developed once but deployed on many different
> > kernel versions simultaneously, as part of continuous integration.
>
> Interesting. It seems like it's really in direct competition with KUnit.
I won't speak for Knut, but I don't think we are in competition. I see
KTF as a novel way to do a kind of white box end-to-end testing for
the Linux kernel, which is a valuable thing, especially in some
circumstances. I could see KTF having a lot of value for someone who
wants to maintain out of tree drivers, in particular.
Nevertheless, I don't really see KTF as a real unit testing framework
for a number of different reasons; you pointed out some below, but I
think the main one being that it requires booting a real kernel on
actual hardware; I imagine it could be made to work on a VM, but that
isn't really the point; it fundamentally depends on having part of the
test, or at least driving the test from userspace on top of the kernel
under test. Knut, myself, and others, had a previous discussion to
this effect here: https://lkml.org/lkml/2018/11/24/170
> I didn't really go into it in too much detail but these are my thoughts:
>
> From a developer perspective I think KTF not being in the kernel tree is
> a huge negative. I want minimal effort to include my tests in a patch
> series and minimal effort for other developers to be able to use them.
> Needing to submit these tests to another project or use another project
> to run them is too much friction.
>
> Also I think the goal of having tests that run on any kernel version is
> a pipe dream. You'd absolutely need a way to encode which kernel
> versions a test is expected to pass on because the tests might not make
> sense until a feature is finished in upstream. And this makes it even
> harder to develop these tests because, when we write them, we might not
> even know which kernel version the feature will be added to. Similarly,
> if a feature is removed or substantially changed, someone will have to
> do a patch to disable the test for subsequent kernel versions and create
> a new test for changed features. So, IMO, tests absolutely have to be
> part of the kernel tree so they can be changed with the respective
> features they test.
>
> Kunit's ability to run without having to build and run the entire kernel
> is also a huge plus. (Assuming there's a way to get around the build
> dependency issues). Because of this, it can be very quick to run these
> tests which makes development a *lot* easier seeing you don't have to
> reboot a machine every time you want to test a fix.
I will reply to your comments directly on your original email. I don't
want to hijack this thread, in case we want to discuss the topic of
KUnit vs. KTF further.
WARNING: multiple messages have this Message-ID (diff)
From: Brendan Higgins <brendanhiggins@google.com>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Knut Omang <knut.omang@oracle.com>,
Kees Cook <keescook@google.com>,
Luis Chamberlain <mcgrof@kernel.org>,
shuah@kernel.org, Rob Herring <robh@kernel.org>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
Frank Rowand <frowand.list@gmail.com>,
Greg KH <gregkh@linuxfoundation.org>,
Joel Stanley <joel@jms.id.au>,
Michael Ellerman <mpe@ellerman.id.au>,
Joe Perches <joe@perches.com>,
brakmo@fb.com, Steven Rostedt <rostedt@goodmis.org>,
"Bird, Timothy" <Tim.Bird@sony.com>,
Kevin Hilman <khilman@baylibre.com>,
Julia Lawall <julia.lawall@lip6.fr>,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jeff Dike <jdike@addtoit.com>,
Richard Weinberger <richard@nod.at>,
linux-um@lists.infradead.org, Daniel Vetter <daniel@ffwll.ch>,
dri-devel <dri-devel@lists.freedesktop.org>,
Dan Williams <dan.j.williams@intel.com>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
devicetree <devicetree@vger.kernel.org>,
Petr Mladek <pmladek@suse.com>,
Sasha Levin <Alexander.Levin@microsoft.com>,
Amir Goldstein <amir73il@gmail.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
wfg@linux.intel.com
Subject: Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
Date: Thu, 21 Mar 2019 09:55:12 -0700 [thread overview]
Message-ID: <CAFd5g45LKU+SZAFzn3RNCoxhzum0NAr9t+UJ80SJDMc_FeKgBQ@mail.gmail.com> (raw)
In-Reply-To: <ce355f5c-189c-816c-cde4-fb4e816d44e7@deltatee.com>
On Thu, Mar 21, 2019 at 8:56 AM Logan Gunthorpe <logang@deltatee.com> wrote:
>
>
>
> On 2019-03-20 11:23 p.m., Knut Omang wrote:
> > Testing drivers, hardware and firmware within production kernels was the use
> > case that inspired KTF (Kernel Test Framework). Currently KTF is available as a
> > standalone git repository. That's been the most efficient form for us so far,
> > as we typically want tests to be developed once but deployed on many different
> > kernel versions simultaneously, as part of continuous integration.
>
> Interesting. It seems like it's really in direct competition with KUnit.
I won't speak for Knut, but I don't think we are in competition. I see
KTF as a novel way to do a kind of white box end-to-end testing for
the Linux kernel, which is a valuable thing, especially in some
circumstances. I could see KTF having a lot of value for someone who
wants to maintain out of tree drivers, in particular.
Nevertheless, I don't really see KTF as a real unit testing framework
for a number of different reasons; you pointed out some below, but I
think the main one being that it requires booting a real kernel on
actual hardware; I imagine it could be made to work on a VM, but that
isn't really the point; it fundamentally depends on having part of the
test, or at least driving the test from userspace on top of the kernel
under test. Knut, myself, and others, had a previous discussion to
this effect here: https://lkml.org/lkml/2018/11/24/170
> I didn't really go into it in too much detail but these are my thoughts:
>
> From a developer perspective I think KTF not being in the kernel tree is
> a huge negative. I want minimal effort to include my tests in a patch
> series and minimal effort for other developers to be able to use them.
> Needing to submit these tests to another project or use another project
> to run them is too much friction.
>
> Also I think the goal of having tests that run on any kernel version is
> a pipe dream. You'd absolutely need a way to encode which kernel
> versions a test is expected to pass on because the tests might not make
> sense until a feature is finished in upstream. And this makes it even
> harder to develop these tests because, when we write them, we might not
> even know which kernel version the feature will be added to. Similarly,
> if a feature is removed or substantially changed, someone will have to
> do a patch to disable the test for subsequent kernel versions and create
> a new test for changed features. So, IMO, tests absolutely have to be
> part of the kernel tree so they can be changed with the respective
> features they test.
>
> Kunit's ability to run without having to build and run the entire kernel
> is also a huge plus. (Assuming there's a way to get around the build
> dependency issues). Because of this, it can be very quick to run these
> tests which makes development a *lot* easier seeing you don't have to
> reboot a machine every time you want to test a fix.
I will reply to your comments directly on your original email. I don't
want to hijack this thread, in case we want to discuss the topic of
KUnit vs. KTF further.
WARNING: multiple messages have this Message-ID (diff)
From: brendanhiggins at google.com (Brendan Higgins)
Subject: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
Date: Thu, 21 Mar 2019 09:55:12 -0700 [thread overview]
Message-ID: <CAFd5g45LKU+SZAFzn3RNCoxhzum0NAr9t+UJ80SJDMc_FeKgBQ@mail.gmail.com> (raw)
In-Reply-To: <ce355f5c-189c-816c-cde4-fb4e816d44e7@deltatee.com>
On Thu, Mar 21, 2019 at 8:56 AM Logan Gunthorpe <logang at deltatee.com> wrote:
>
>
>
> On 2019-03-20 11:23 p.m., Knut Omang wrote:
> > Testing drivers, hardware and firmware within production kernels was the use
> > case that inspired KTF (Kernel Test Framework). Currently KTF is available as a
> > standalone git repository. That's been the most efficient form for us so far,
> > as we typically want tests to be developed once but deployed on many different
> > kernel versions simultaneously, as part of continuous integration.
>
> Interesting. It seems like it's really in direct competition with KUnit.
I won't speak for Knut, but I don't think we are in competition. I see
KTF as a novel way to do a kind of white box end-to-end testing for
the Linux kernel, which is a valuable thing, especially in some
circumstances. I could see KTF having a lot of value for someone who
wants to maintain out of tree drivers, in particular.
Nevertheless, I don't really see KTF as a real unit testing framework
for a number of different reasons; you pointed out some below, but I
think the main one being that it requires booting a real kernel on
actual hardware; I imagine it could be made to work on a VM, but that
isn't really the point; it fundamentally depends on having part of the
test, or at least driving the test from userspace on top of the kernel
under test. Knut, myself, and others, had a previous discussion to
this effect here: https://lkml.org/lkml/2018/11/24/170
> I didn't really go into it in too much detail but these are my thoughts:
>
> From a developer perspective I think KTF not being in the kernel tree is
> a huge negative. I want minimal effort to include my tests in a patch
> series and minimal effort for other developers to be able to use them.
> Needing to submit these tests to another project or use another project
> to run them is too much friction.
>
> Also I think the goal of having tests that run on any kernel version is
> a pipe dream. You'd absolutely need a way to encode which kernel
> versions a test is expected to pass on because the tests might not make
> sense until a feature is finished in upstream. And this makes it even
> harder to develop these tests because, when we write them, we might not
> even know which kernel version the feature will be added to. Similarly,
> if a feature is removed or substantially changed, someone will have to
> do a patch to disable the test for subsequent kernel versions and create
> a new test for changed features. So, IMO, tests absolutely have to be
> part of the kernel tree so they can be changed with the respective
> features they test.
>
> Kunit's ability to run without having to build and run the entire kernel
> is also a huge plus. (Assuming there's a way to get around the build
> dependency issues). Because of this, it can be very quick to run these
> tests which makes development a *lot* easier seeing you don't have to
> reboot a machine every time you want to test a fix.
I will reply to your comments directly on your original email. I don't
want to hijack this thread, in case we want to discuss the topic of
KUnit vs. KTF further.
WARNING: multiple messages have this Message-ID (diff)
From: brendanhiggins@google.com (Brendan Higgins)
Subject: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
Date: Thu, 21 Mar 2019 09:55:12 -0700 [thread overview]
Message-ID: <CAFd5g45LKU+SZAFzn3RNCoxhzum0NAr9t+UJ80SJDMc_FeKgBQ@mail.gmail.com> (raw)
Message-ID: <20190321165512.l3PRK_OzOmpyrav-hXctSbV7QkHbXD6x1dexyS09a3I@z> (raw)
In-Reply-To: <ce355f5c-189c-816c-cde4-fb4e816d44e7@deltatee.com>
On Thu, Mar 21, 2019@8:56 AM Logan Gunthorpe <logang@deltatee.com> wrote:
>
>
>
> On 2019-03-20 11:23 p.m., Knut Omang wrote:
> > Testing drivers, hardware and firmware within production kernels was the use
> > case that inspired KTF (Kernel Test Framework). Currently KTF is available as a
> > standalone git repository. That's been the most efficient form for us so far,
> > as we typically want tests to be developed once but deployed on many different
> > kernel versions simultaneously, as part of continuous integration.
>
> Interesting. It seems like it's really in direct competition with KUnit.
I won't speak for Knut, but I don't think we are in competition. I see
KTF as a novel way to do a kind of white box end-to-end testing for
the Linux kernel, which is a valuable thing, especially in some
circumstances. I could see KTF having a lot of value for someone who
wants to maintain out of tree drivers, in particular.
Nevertheless, I don't really see KTF as a real unit testing framework
for a number of different reasons; you pointed out some below, but I
think the main one being that it requires booting a real kernel on
actual hardware; I imagine it could be made to work on a VM, but that
isn't really the point; it fundamentally depends on having part of the
test, or at least driving the test from userspace on top of the kernel
under test. Knut, myself, and others, had a previous discussion to
this effect here: https://lkml.org/lkml/2018/11/24/170
> I didn't really go into it in too much detail but these are my thoughts:
>
> From a developer perspective I think KTF not being in the kernel tree is
> a huge negative. I want minimal effort to include my tests in a patch
> series and minimal effort for other developers to be able to use them.
> Needing to submit these tests to another project or use another project
> to run them is too much friction.
>
> Also I think the goal of having tests that run on any kernel version is
> a pipe dream. You'd absolutely need a way to encode which kernel
> versions a test is expected to pass on because the tests might not make
> sense until a feature is finished in upstream. And this makes it even
> harder to develop these tests because, when we write them, we might not
> even know which kernel version the feature will be added to. Similarly,
> if a feature is removed or substantially changed, someone will have to
> do a patch to disable the test for subsequent kernel versions and create
> a new test for changed features. So, IMO, tests absolutely have to be
> part of the kernel tree so they can be changed with the respective
> features they test.
>
> Kunit's ability to run without having to build and run the entire kernel
> is also a huge plus. (Assuming there's a way to get around the build
> dependency issues). Because of this, it can be very quick to run these
> tests which makes development a *lot* easier seeing you don't have to
> reboot a machine every time you want to test a fix.
I will reply to your comments directly on your original email. I don't
want to hijack this thread, in case we want to discuss the topic of
KUnit vs. KTF further.
WARNING: multiple messages have this Message-ID (diff)
From: Brendan Higgins <brendanhiggins@google.com>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: brakmo@fb.com, Petr Mladek <pmladek@suse.com>,
Amir Goldstein <amir73il@gmail.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
Sasha Levin <Alexander.Levin@microsoft.com>,
linux-kselftest@vger.kernel.org,
Frank Rowand <frowand.list@gmail.com>,
Rob Herring <robh@kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Richard Weinberger <richard@nod.at>,
Knut Omang <knut.omang@oracle.com>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
wfg@linux.intel.com, Joel Stanley <joel@jms.id.au>,
Jeff Dike <jdike@addtoit.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
devicetree <devicetree@vger.kernel.org>,
shuah@kernel.org, "Bird," Timothy" <Tim.Bird@sony.com>,
Kees Cook <keescook@google.com>," linux-um@lists.infradead.org,
Steven Rostedt <rostedt@goodmis.org>,
Julia Lawall <julia.lawall@lip6.fr>,
Dan Williams <dan.j.williams@intel.com>,
kunit-dev@googlegroups.com, Greg KH <gregkh@linuxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Daniel Vetter <daniel@ffwll.ch>,
Michael Ellerman <mpe@ellerman.id.au>,
Joe Perches <joe@perches.com>,
Kevin Hilman <khilman@baylibre.com>
Subject: Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
Date: Thu, 21 Mar 2019 09:55:12 -0700 [thread overview]
Message-ID: <CAFd5g45LKU+SZAFzn3RNCoxhzum0NAr9t+UJ80SJDMc_FeKgBQ@mail.gmail.com> (raw)
In-Reply-To: <ce355f5c-189c-816c-cde4-fb4e816d44e7@deltatee.com>
On Thu, Mar 21, 2019 at 8:56 AM Logan Gunthorpe <logang@deltatee.com> wrote:
>
>
>
> On 2019-03-20 11:23 p.m., Knut Omang wrote:
> > Testing drivers, hardware and firmware within production kernels was the use
> > case that inspired KTF (Kernel Test Framework). Currently KTF is available as a
> > standalone git repository. That's been the most efficient form for us so far,
> > as we typically want tests to be developed once but deployed on many different
> > kernel versions simultaneously, as part of continuous integration.
>
> Interesting. It seems like it's really in direct competition with KUnit.
I won't speak for Knut, but I don't think we are in competition. I see
KTF as a novel way to do a kind of white box end-to-end testing for
the Linux kernel, which is a valuable thing, especially in some
circumstances. I could see KTF having a lot of value for someone who
wants to maintain out of tree drivers, in particular.
Nevertheless, I don't really see KTF as a real unit testing framework
for a number of different reasons; you pointed out some below, but I
think the main one being that it requires booting a real kernel on
actual hardware; I imagine it could be made to work on a VM, but that
isn't really the point; it fundamentally depends on having part of the
test, or at least driving the test from userspace on top of the kernel
under test. Knut, myself, and others, had a previous discussion to
this effect here: https://lkml.org/lkml/2018/11/24/170
> I didn't really go into it in too much detail but these are my thoughts:
>
> From a developer perspective I think KTF not being in the kernel tree is
> a huge negative. I want minimal effort to include my tests in a patch
> series and minimal effort for other developers to be able to use them.
> Needing to submit these tests to another project or use another project
> to run them is too much friction.
>
> Also I think the goal of having tests that run on any kernel version is
> a pipe dream. You'd absolutely need a way to encode which kernel
> versions a test is expected to pass on because the tests might not make
> sense until a feature is finished in upstream. And this makes it even
> harder to develop these tests because, when we write them, we might not
> even know which kernel version the feature will be added to. Similarly,
> if a feature is removed or substantially changed, someone will have to
> do a patch to disable the test for subsequent kernel versions and create
> a new test for changed features. So, IMO, tests absolutely have to be
> part of the kernel tree so they can be changed with the respective
> features they test.
>
> Kunit's ability to run without having to build and run the entire kernel
> is also a huge plus. (Assuming there's a way to get around the build
> dependency issues). Because of this, it can be very quick to run these
> tests which makes development a *lot* easier seeing you don't have to
> reboot a machine every time you want to test a fix.
I will reply to your comments directly on your original email. I don't
want to hijack this thread, in case we want to discuss the topic of
KUnit vs. KTF further.
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2019-03-21 16:55 UTC|newest]
Thread overview: 316+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 21:37 [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` [RFC v4 02/17] kunit: test: add test resource management API Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-15 21:01 ` Stephen Boyd
2019-02-15 21:01 ` Stephen Boyd
2019-02-15 21:01 ` Stephen Boyd
2019-02-15 21:01 ` sboyd
2019-02-15 21:01 ` Stephen Boyd
2019-02-19 23:24 ` Brendan Higgins
2019-02-19 23:24 ` Brendan Higgins
2019-02-19 23:24 ` Brendan Higgins
2019-02-19 23:24 ` brendanhiggins
2019-02-19 23:24 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 07/17] kunit: test: add initial tests Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` [RFC v4 16/17] of: unittest: split out a couple of test cases from unittest Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-03-22 1:14 ` Frank Rowand
2019-03-22 1:14 ` Frank Rowand
2019-03-22 1:14 ` Frank Rowand
2019-03-22 1:14 ` frowand.list
2019-03-22 1:14 ` Frank Rowand
2019-03-22 1:45 ` Brendan Higgins
2019-03-22 1:45 ` Brendan Higgins
2019-03-22 1:45 ` Brendan Higgins
2019-03-22 1:45 ` brendanhiggins
2019-03-22 1:45 ` Brendan Higgins
2019-03-22 1:45 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 17/17] of: unittest: split up some super large test cases Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-03-22 1:16 ` Frank Rowand
2019-03-22 1:16 ` Frank Rowand
2019-03-22 1:16 ` Frank Rowand
2019-03-22 1:16 ` frowand.list
2019-03-22 1:16 ` Frank Rowand
2019-03-22 1:16 ` Frank Rowand
[not found] ` <09b06e6d-fd36-707e-cb7a-e935bd930510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-22 1:45 ` Brendan Higgins
2019-03-22 1:45 ` Brendan Higgins
2019-03-22 1:45 ` Brendan Higgins
2019-03-22 1:45 ` brendanhiggins
2019-03-22 1:45 ` Brendan Higgins
2019-02-18 20:02 ` [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Frank Rowand
2019-02-18 20:02 ` Frank Rowand
2019-02-18 20:02 ` Frank Rowand
2019-02-18 20:02 ` frowand.list
2019-02-20 6:34 ` Brendan Higgins
2019-02-20 6:34 ` Brendan Higgins
2019-02-20 6:34 ` Brendan Higgins
2019-02-20 6:34 ` brendanhiggins
2019-02-20 6:34 ` Brendan Higgins
2019-02-20 6:46 ` Frank Rowand
2019-02-20 6:46 ` Frank Rowand
2019-02-20 6:46 ` Frank Rowand
2019-02-20 6:46 ` frowand.list
2019-02-20 6:46 ` Frank Rowand
2019-02-22 20:52 ` Thiago Jung Bauermann
2019-02-22 20:52 ` Thiago Jung Bauermann
2019-02-22 20:52 ` Thiago Jung Bauermann
2019-02-22 20:52 ` bauerman
2019-02-22 20:52 ` Thiago Jung Bauermann
2019-02-28 4:18 ` Brendan Higgins
2019-02-28 4:18 ` Brendan Higgins
2019-02-28 4:18 ` brendanhiggins
2019-02-28 4:18 ` Brendan Higgins
2019-02-28 4:15 ` Brendan Higgins
2019-02-28 4:15 ` Brendan Higgins
2019-02-28 4:15 ` Brendan Higgins
2019-02-28 4:15 ` brendanhiggins
2019-02-28 4:15 ` Brendan Higgins
2019-03-04 23:01 ` Brendan Higgins
2019-03-04 23:01 ` Brendan Higgins
2019-03-04 23:01 ` Brendan Higgins
2019-03-04 23:01 ` brendanhiggins
2019-03-04 23:01 ` Brendan Higgins
2019-03-22 1:23 ` Frank Rowand
2019-03-22 1:23 ` Frank Rowand
2019-03-22 1:23 ` Frank Rowand
2019-03-22 1:23 ` frowand.list
2019-03-22 1:23 ` Frank Rowand
2019-03-22 1:23 ` Frank Rowand
[not found] ` <0e6eb370-3e62-e1a5-1b91-bccc5868e8e4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-25 22:11 ` Brendan Higgins
2019-03-25 22:11 ` Brendan Higgins
2019-03-25 22:11 ` Brendan Higgins
2019-03-25 22:11 ` brendanhiggins
2019-03-25 22:11 ` Brendan Higgins
[not found] ` <20190214213729.21702-1-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2019-02-14 21:37 ` [RFC v4 01/17] kunit: test: add KUnit test runner core Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 03/17] kunit: test: add string_stream a std::stream like string builder Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 04/17] kunit: test: add test_stream a std::stream like logger Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 05/17] kunit: test: add the concept of expectations Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 06/17] kbuild: enable building KUnit Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 08/17] kunit: test: add support for test abort Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
[not found] ` <20190214213729.21702-9-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2019-02-18 19:52 ` Frank Rowand
2019-02-18 19:52 ` Frank Rowand
2019-02-18 19:52 ` frowand.list
2019-02-18 19:52 ` Frank Rowand
[not found] ` <da1995fa-a362-dfe6-8184-7fcdf2b923e8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-02-20 3:39 ` Brendan Higgins
2019-02-20 3:39 ` Brendan Higgins
2019-02-20 3:39 ` Brendan Higgins
2019-02-20 3:39 ` brendanhiggins
2019-02-20 3:39 ` Brendan Higgins
2019-02-20 6:44 ` Frank Rowand
2019-02-20 6:44 ` Frank Rowand
2019-02-20 6:44 ` Frank Rowand
2019-02-20 6:44 ` frowand.list
2019-02-20 6:44 ` Frank Rowand
2019-02-20 6:44 ` Frank Rowand
2019-02-28 7:42 ` Brendan Higgins
2019-02-28 7:42 ` Brendan Higgins
2019-02-28 7:42 ` Brendan Higgins
2019-02-28 7:42 ` brendanhiggins
2019-02-28 7:42 ` Brendan Higgins
[not found] ` <CAFd5g47EDmsBWKNiW0jpHW2VG_GWCfe8UO+=ofgM2_ru+_UBQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-22 1:09 ` Frank Rowand
2019-03-22 1:09 ` Frank Rowand
2019-03-22 1:09 ` Frank Rowand
2019-03-22 1:09 ` frowand.list
2019-03-22 1:09 ` Frank Rowand
2019-03-22 1:41 ` Brendan Higgins
2019-03-22 1:41 ` Brendan Higgins
2019-03-22 1:41 ` Brendan Higgins
2019-03-22 1:41 ` brendanhiggins
2019-03-22 1:41 ` Brendan Higgins
[not found] ` <CAFd5g46AP9yZQ+z+60HGaZuqhJQmfSBw9+r62w4k=cGiMEkqLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-22 7:10 ` Knut Omang
2019-03-22 7:10 ` Knut Omang
2019-03-22 7:10 ` Knut Omang
2019-03-22 7:10 ` knut.omang
2019-03-22 7:10 ` Knut Omang
2019-03-25 22:32 ` Brendan Higgins
2019-03-25 22:32 ` Brendan Higgins
2019-03-25 22:32 ` brendanhiggins
2019-03-25 22:32 ` Brendan Higgins
[not found] ` <CAFd5g44eqjN-nVCJuoeYFCxwVa5AorWiAnXe-tFCAc11zDgJFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-26 7:44 ` Knut Omang
2019-03-26 7:44 ` Knut Omang
2019-03-26 7:44 ` Knut Omang
2019-03-26 7:44 ` knut.omang
2019-03-26 7:44 ` Knut Omang
2019-02-26 20:35 ` Stephen Boyd
2019-02-26 20:35 ` Stephen Boyd
2019-02-26 20:35 ` Stephen Boyd
2019-02-26 20:35 ` sboyd
2019-02-26 20:35 ` Stephen Boyd
[not found] ` <155121334527.260864.5324117081460979741-n1Xw8LXHxjTHt/MElyovVYaSKrA+ACpX0E9HWUfgJXw@public.gmane.org>
2019-02-28 9:03 ` Brendan Higgins
2019-02-28 9:03 ` Brendan Higgins
2019-02-28 9:03 ` brendanhiggins
2019-02-28 9:03 ` Brendan Higgins
2019-02-28 13:54 ` Dan Carpenter
2019-02-28 13:54 ` Dan Carpenter
2019-02-28 13:54 ` Dan Carpenter
2019-02-28 13:54 ` dan.carpenter
2019-02-28 13:54 ` Dan Carpenter
2019-03-04 22:28 ` Brendan Higgins
2019-03-04 22:28 ` Brendan Higgins
2019-03-04 22:28 ` Brendan Higgins
2019-03-04 22:28 ` brendanhiggins
2019-03-04 22:28 ` Brendan Higgins
2019-02-28 18:02 ` Stephen Boyd
2019-02-28 18:02 ` Stephen Boyd
[not found] ` <155137694423.260864.2846034318906225490-n1Xw8LXHxjTHt/MElyovVYaSKrA+ACpX0E9HWUfgJXw@public.gmane.org>
2019-03-04 22:39 ` Brendan Higgins
2019-03-04 22:39 ` Brendan Higgins
2019-03-04 22:39 ` Brendan Higgins
2019-03-04 22:39 ` brendanhiggins
2019-03-04 22:39 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 09/17] kunit: test: add the concept of assertions Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 10/17] kunit: test: add test managed resource tests Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
[not found] ` <20190214213729.21702-11-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2019-02-15 20:54 ` Stephen Boyd
2019-02-15 20:54 ` Stephen Boyd
2019-02-15 20:54 ` Stephen Boyd
2019-02-15 20:54 ` sboyd
2019-02-15 20:54 ` Stephen Boyd
2019-02-19 23:20 ` Brendan Higgins
2019-02-19 23:20 ` Brendan Higgins
2019-02-19 23:20 ` Brendan Higgins
2019-02-19 23:20 ` brendanhiggins
2019-02-19 23:20 ` Brendan Higgins
2019-02-20 22:03 ` Stephen Boyd
2019-02-20 22:03 ` Stephen Boyd
2019-02-14 21:37 ` [RFC v4 11/17] kunit: tool: add Python wrappers for running KUnit tests Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 12/17] kunit: defconfig: add defconfigs for building " Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 13/17] Documentation: kunit: add documentation for KUnit Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 14/17] MAINTAINERS: add entry for KUnit the unit testing framework Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` [RFC v4 15/17] of: unittest: migrate tests to run on KUnit Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` Brendan Higgins
2019-02-14 21:37 ` brendanhiggins
2019-02-14 21:37 ` Brendan Higgins
[not found] ` <20190214213729.21702-16-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2019-02-16 0:24 ` Frank Rowand
2019-02-16 0:24 ` Frank Rowand
2019-02-16 0:24 ` Frank Rowand
2019-02-16 0:24 ` frowand.list
2019-02-16 0:24 ` Frank Rowand
[not found] ` <cda7c8db-a6d0-6a93-5c33-9ccf32dfd29a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-02-20 2:24 ` Brendan Higgins
2019-02-20 2:24 ` Brendan Higgins
2019-02-20 2:24 ` Brendan Higgins
2019-02-20 2:24 ` brendanhiggins
2019-02-20 2:24 ` Brendan Higgins
2019-03-21 1:07 ` [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Logan Gunthorpe
2019-03-21 1:07 ` Logan Gunthorpe
2019-03-21 1:07 ` Logan Gunthorpe
2019-03-21 1:07 ` logang
2019-03-21 1:07 ` Logan Gunthorpe
[not found] ` <6d9b3b21-1179-3a45-7545-30aa15306cb4-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-03-21 5:23 ` Knut Omang
2019-03-21 5:23 ` Knut Omang
2019-03-21 5:23 ` Knut Omang
2019-03-21 5:23 ` knut.omang
2019-03-21 5:23 ` Knut Omang
2019-03-21 15:56 ` Logan Gunthorpe
2019-03-21 15:56 ` Logan Gunthorpe
2019-03-21 15:56 ` Logan Gunthorpe
2019-03-21 15:56 ` logang
2019-03-21 15:56 ` Logan Gunthorpe
2019-03-21 15:56 ` Logan Gunthorpe
[not found] ` <ce355f5c-189c-816c-cde4-fb4e816d44e7-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-03-21 16:55 ` Brendan Higgins [this message]
2019-03-21 16:55 ` Brendan Higgins
2019-03-21 16:55 ` Brendan Higgins
2019-03-21 16:55 ` brendanhiggins
2019-03-21 16:55 ` Brendan Higgins
[not found] ` <CAFd5g45LKU+SZAFzn3RNCoxhzum0NAr9t+UJ80SJDMc_FeKgBQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-21 19:13 ` Knut Omang
2019-03-21 19:13 ` Knut Omang
2019-03-21 19:13 ` Knut Omang
2019-03-21 19:13 ` knut.omang
2019-03-21 19:13 ` Knut Omang
2019-03-21 19:29 ` Logan Gunthorpe
2019-03-21 19:29 ` Logan Gunthorpe
2019-03-21 19:29 ` Logan Gunthorpe
2019-03-21 19:29 ` logang
2019-03-21 19:29 ` Logan Gunthorpe
2019-03-21 19:29 ` Logan Gunthorpe
[not found] ` <961494a3-d08c-2720-c59d-7d7008edb288-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2019-03-21 20:14 ` Knut Omang
2019-03-21 20:14 ` Knut Omang
2019-03-21 20:14 ` Knut Omang
2019-03-21 20:14 ` knut.omang
2019-03-21 20:14 ` Knut Omang
2019-03-21 22:07 ` Brendan Higgins
2019-03-21 22:07 ` Brendan Higgins
2019-03-21 22:07 ` Brendan Higgins
2019-03-21 22:07 ` brendanhiggins
2019-03-21 22:07 ` Brendan Higgins
2019-03-21 22:26 ` Logan Gunthorpe
2019-03-21 22:26 ` Logan Gunthorpe
2019-03-21 22:26 ` Logan Gunthorpe
2019-03-21 22:26 ` logang
2019-03-21 22:26 ` Logan Gunthorpe
2019-03-21 23:33 ` Brendan Higgins
2019-03-21 23:33 ` Brendan Higgins
2019-03-21 23:33 ` Brendan Higgins
2019-03-21 23:33 ` brendanhiggins
2019-03-21 23:33 ` Brendan Higgins
2019-03-22 1:12 ` Frank Rowand
2019-03-22 1:12 ` Frank Rowand
2019-03-22 1:12 ` Frank Rowand
2019-03-22 1:12 ` frowand.list
2019-03-22 1:12 ` Frank Rowand
2019-03-22 1:12 ` Frank Rowand
[not found] ` <aea24c8e-5ce8-5f33-c81b-d2eeef588ec8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-25 22:12 ` Brendan Higgins
2019-03-25 22:12 ` Brendan Higgins
2019-03-25 22:12 ` Brendan Higgins
2019-03-25 22:12 ` brendanhiggins
2019-03-25 22:12 ` Brendan Higgins
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=CAFd5g45LKU+SZAFzn3RNCoxhzum0NAr9t+UJ80SJDMc_FeKgBQ@mail.gmail.com \
--to=brendanhiggins-hpiqsd4aklfqt0dzr+alfa@public.gmane.org \
--cc=Alexander.Levin-0li6OtcxBFHby3iVrkZq2A@public.gmane.org \
--cc=Tim.Bird-7U/KSKJipcs@public.gmane.org \
--cc=amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=brakmo-b10kYP2dOMg@public.gmane.org \
--cc=dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=jdike-OPE4K8JWMJJBDgjK7y7TUQ@public.gmane.org \
--cc=joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org \
--cc=julia.lawall-L2FTfq7BK8M@public.gmane.org \
--cc=keescook-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=kieran.bingham-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
--cc=knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=kunit-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
--cc=linux-kselftest-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
--cc=linux-um-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org \
--cc=pmladek-IBi9RG/b67k@public.gmane.org \
--cc=richard-/L3Ra7n9ekc@public.gmane.org \
--cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org \
--cc=shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.