From: Brendan Higgins <brendanhiggins@google.com>
To: Knut Omang <knut.omang@oracle.com>
Cc: Frank Rowand <frowand.list@gmail.com>,
Daniel Vetter <daniel@ffwll.ch>,
Logan Gunthorpe <logang@deltatee.com>,
Theodore Ts'o <tytso@mit.edu>,
"Bird, Timothy" <Tim.Bird@sony.com>,
Greg KH <gregkh@linuxfoundation.org>,
Kees Cook <keescook@google.com>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
Rob Herring <robh@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
Shuah Khan <shuah@kernel.org>,
devicetree <devicetree@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
kunit-dev@googlegroups.com,
Linux Doc Mailing List <linux-doc@vger.kernel.org>,
linux-fsdevel@vger.kernel.org,
linux-kbuild <linux-kbuild@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
linux-um@lists.infradead.org,
Sasha Levin <Alexander.Levin@microsoft.com>,
Amir Goldstein <amir73il@gmail.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
Dan Williams <dan.j.williams@intel.com>,
Jeff Dike <jdike@addtoit.com>, Joel Stanley <joel@jms.id.au>,
Julia Lawall <julia.lawall@lip6.fr>,
Kevin Hilman <khilman@baylibre.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Petr Mladek <pmladek@suse.com>,
Richard Weinberger <richard@nod.at>,
David Rientjes <rientjes@google.com>,
Steven Rostedt <rostedt@goodmis.org>,
wfg@linux.intel.com
Subject: Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
Date: Mon, 13 May 2019 23:39:53 -0700 [thread overview]
Message-ID: <20190514063953.GB181462@google.com> (raw)
In-Reply-To: <b3dd7e40149184f5823b66764a20dee3c9905ed1.camel@oracle.com>
On Sat, May 11, 2019 at 08:17:47AM +0200, Knut Omang wrote:
> On Fri, 2019-05-10 at 15:18 -0700, Frank Rowand wrote:
> > On 5/10/19 1:54 PM, Brendan Higgins wrote:
> > > On Fri, May 10, 2019 at 5:13 AM Knut Omang <knut.omang@oracle.com> wrote:
> > >> On Fri, 2019-05-10 at 03:23 -0700, Brendan Higgins wrote:
> > >>>> On Fri, May 10, 2019 at 7:49 AM Knut Omang <knut.omang@oracle.com> wrote:
> > >>>>>
> > >>>>> On Thu, 2019-05-09 at 22:18 -0700, Frank Rowand wrote:
> > >>>>>> On 5/9/19 4:40 PM, Logan Gunthorpe wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 2019-05-09 5:30 p.m., Theodore Ts'o wrote:
> > >>>>>>>> On Thu, May 09, 2019 at 04:20:05PM -0600, Logan Gunthorpe wrote:
> > >>>>>>>>>
> > >>>>>>>>> The second item, arguably, does have significant overlap with kselftest.
> > >>>>>>>>> Whether you are running short tests in a light weight UML environment or
> > >>>>>>>>> higher level tests in an heavier VM the two could be using the same
> > >>>>>>>>> framework for writing or defining in-kernel tests. It *may* also be valuable
> > >>>>>>>>> for some people to be able to run all the UML tests in the heavy VM
> > >>>>>>>>> environment along side other higher level tests.
> > >>>>>>>>>
> > >>>>>>>>> Looking at the selftests tree in the repo, we already have similar items to
> > >>>>>>>>> what Kunit is adding as I described in point (2) above. kselftest_harness.h
> > >>>>>>>>> contains macros like EXPECT_* and ASSERT_* with very similar intentions to
> > >>>>>>>>> the new KUNIT_EXECPT_* and KUNIT_ASSERT_* macros.
> > >>>>>>>>>
> > >>>>>>>>> However, the number of users of this harness appears to be quite small. Most
> > >>>>>>>>> of the code in the selftests tree seems to be a random mismash of scripts
> > >>>>>>>>> and userspace code so it's not hard to see it as something completely
> > >>>>>>>>> different from the new Kunit:
> > >>>>>>>>>
> > >>>>>>>>> $ git grep --files-with-matches kselftest_harness.h *
> > >>>>>>>>
> > >>>>>>>> To the extent that we can unify how tests are written, I agree that
> > >>>>>>>> this would be a good thing. However, you should note that
> > >>>>>>>> kselftest_harness.h is currently assums that it will be included in
> > >>>>>>>> userspace programs. This is most obviously seen if you look closely
> > >>>>>>>> at the functions defined in the header files which makes calls to
> > >>>>>>>> fork(), abort() and fprintf().
> > >>>>>>>
> > >>>>>>> Ah, yes. I obviously did not dig deep enough. Using kunit for
> > >>>>>>> in-kernel tests and kselftest_harness for userspace tests seems like
> > >>>>>>> a sensible line to draw to me. Trying to unify kernel and userspace
> > >>>>>>> here sounds like it could be difficult so it's probably not worth
> > >>>>>>> forcing the issue unless someone wants to do some really fancy work
> > >>>>>>> to get it done.
> > >>>>>>>
> > >>>>>>> Based on some of the other commenters, I was under the impression
> > >>>>>>> that kselftests had in-kernel tests but I'm not sure where or if they
> > >>>>>>> exist.
> > >>>>>>
> > >>>>>> YES, kselftest has in-kernel tests. (Excuse the shouting...)
> > >>>>>>
> > >>>>>> Here is a likely list of them in the kernel source tree:
> > >>>>>>
> > >>>>>> $ grep module_init lib/test_*.c
> > >>>>>> lib/test_bitfield.c:module_init(test_bitfields)
> > >>>>>> lib/test_bitmap.c:module_init(test_bitmap_init);
> > >>>>>> lib/test_bpf.c:module_init(test_bpf_init);
> > >>>>>> lib/test_debug_virtual.c:module_init(test_debug_virtual_init);
> > >>>>>> lib/test_firmware.c:module_init(test_firmware_init);
> > >>>>>> lib/test_hash.c:module_init(test_hash_init); /* Does everything */
> > >>>>>> lib/test_hexdump.c:module_init(test_hexdump_init);
> > >>>>>> lib/test_ida.c:module_init(ida_checks);
> > >>>>>> lib/test_kasan.c:module_init(kmalloc_tests_init);
> > >>>>>> lib/test_list_sort.c:module_init(list_sort_test);
> > >>>>>> lib/test_memcat_p.c:module_init(test_memcat_p_init);
> > >>>>>> lib/test_module.c:static int __init test_module_init(void)
> > >>>>>> lib/test_module.c:module_init(test_module_init);
> > >>>>>> lib/test_objagg.c:module_init(test_objagg_init);
> > >>>>>> lib/test_overflow.c:static int __init test_module_init(void)
> > >>>>>> lib/test_overflow.c:module_init(test_module_init);
> > >>>>>> lib/test_parman.c:module_init(test_parman_init);
> > >>>>>> lib/test_printf.c:module_init(test_printf_init);
> > >>>>>> lib/test_rhashtable.c:module_init(test_rht_init);
> > >>>>>> lib/test_siphash.c:module_init(siphash_test_init);
> > >>>>>> lib/test_sort.c:module_init(test_sort_init);
> > >>>>>> lib/test_stackinit.c:module_init(test_stackinit_init);
> > >>>>>> lib/test_static_key_base.c:module_init(test_static_key_base_init);
> > >>>>>> lib/test_static_keys.c:module_init(test_static_key_init);
> > >>>>>> lib/test_string.c:module_init(string_selftest_init);
> > >>>>>> lib/test_ubsan.c:module_init(test_ubsan_init);
> > >>>>>> lib/test_user_copy.c:module_init(test_user_copy_init);
> > >>>>>> lib/test_uuid.c:module_init(test_uuid_init);
> > >>>>>> lib/test_vmalloc.c:module_init(vmalloc_test_init)
> > >>>>>> lib/test_xarray.c:module_init(xarray_checks);
> > >>>>>>
> > >>>>>>
> > >>>>>>> If they do exists, it seems like it would make sense to
> > >>>>>>> convert those to kunit and have Kunit tests run-able in a VM or
> > >>>>>>> baremetal instance.
> > >>>>>>
> > >>>>>> They already run in a VM.
> > >>>>>>
> > >>>>>> They already run on bare metal.
> > >>>>>>
> > >>>>>> They already run in UML.
> > >>>>>>
> > >>>>>> This is not to say that KUnit does not make sense. But I'm still trying
> > >>>>>> to get a better description of the KUnit features (and there are
> > >>>>>> some).
> > >>>>>
> > >>>>> FYI, I have a master student who looks at converting some of these to KTF, such as
> > >>> for
> > >>>>> instance the XArray tests, which lended themselves quite good to a semi-automated
> > >>>>> conversion.
> > >>>>>
> > >>>>> The result is also a somewhat more compact code as well as the flexibility
> > >>>>> provided by the Googletest executor and the KTF frameworks, such as running
> > selected
> > >>>>> tests, output formatting, debugging features etc.
> > >>>>
> > >>>> So is KTF already in upstream? Or is the plan to unify the KTF and
> > >>>
> > >>> I am not certain about KTF's upstream plans, but I assume that Knut
> > >>> would have CC'ed me on the thread if he had started working on it.
> > >>
> > >> You are on the Github watcher list for KTF?
> > >
> > > Yep! I have been since LPC in 2017.
> > >
> > >> Quite a few of the commits there are preparatory for a forthcoming kernel patch set.
> > >> I'll of course CC: you on the patch set when we send it to the list.
> > >
> > > Awesome! I appreciate it.
> > >
> > >>
> > >>>> Kunit in-kernel test harnesses? Because there's tons of these
> > >>>
> > >>> No, no plan. Knut and I talked about this a good while ago and it
> > >>> seemed that we had pretty fundamentally different approaches both in
> > >>> terms of implementation and end goal. Combining them seemed pretty
> > >>> infeasible, at least from a technical perspective. Anyway, I am sure
> > >>> Knut would like to give him perspective on the matter and I don't want
> > >>> to say too much without first giving him a chance to chime in on the
> > >>> matter.
> > >>
> > >> I need more time to study KUnit details to say, but from a 10k feet perspective:
> > >> I think at least there's a potential for some API unification, in using the same
> > macro
> > >> names. How about removing the KUNIT_ prefix to the test macros ;-) ?
> > >
> > > Heh, heh. That's actually the way I had it in the earliest versions of
> > > KUnit! But that was pretty much the very first thing everyone
> > > complained about. I think I went from no prefix (like you are
> > > suggesting) to TEST_* before the first version of the RFC at the
> > > request of several people I was kicking the idea around with, and then
> > > I think I was asked to go from TEST_* to KUNIT_* in the very first
> > > revision of the RFC.
> > >
> > > In short, I am sympathetic to your suggestion, but I think that is
> > > non-negotiable at this point. The community has a clear policy in
> > > place on the matter, and at this point I would really prefer not to
> > > change all the symbol names again.
> >
> > This would not be the first time that a patch submitter has been
> > told "do B instead of A" for version 1, then told "do C instead of
> > B" for version 2, then told "do A instead of C" for the final version.
> >
> > It sucks, but it happens.
Sure, I have been there before, but I thought those original opinions
were based on a pretty well established convention. Also, I don't think
those original opinions have changed. If they have, please chime in and
correct me.
> Sorry, I must have overlooked the B instead of A instance - otherwise
> I would have objected against it - in addition to the recognizability
> and portability issue I think it is important that these primitives are
> not unnecessary long since they will be written a *lot* of times if things go
> our way.
I get that. That is why I thought I might have been worthy of an
exception. It is definitely easier to write EXPECT_EQ(...) than
KUNIT_EXPECT_EQ(...) or TEST_EXPECT_EQ(...), but no one else seemed to
agree in the past.
Even now, it is only you (and maybe Frank?) telling me to change it; I
would like to maybe hear Shuah, Kees, or Greg chime in on this before I
go about actually chaning it back, as I distinctly remember each of them
telling me that I should go with KUNIT_*.
> And the reason for using unique names elsewhere is to be able to co-exist with
> other components with the same needs. In the case of tests, I believe they are
That's the policy I was talking about.
> in a different category, they are not supposed to be part of production kernels,
> and we want them to be used all over, that should warrant having the ASSERT_ and EXPECT_
> prefixes "reserved" for the purpose, so I would urge some pragmatism here!
I don't disagree. Again, this is what I initially proposed, but no one
agreed with me on this point.
I am not saying no. Nevertheless, this is a pretty consistently applied
pattern for new stuff, and I would really prefer not to make waves on
something that really doesn't matter all that much.
So like I said, if we can get some more discussion on this and it seems
like broad consensus says we can reserve ASSERT_* and EXPECT_*, then I
will go along with it.
> > As an aside, can you point to where the "clear policy in place" is
> > documented, and what the policy is?
Global namespacing policy that Knut mentioned above.
> >
> > -Frank
> >
> >
> > >> That would make the names shorter, saving typing when writing tests, and storage ;-)
> > >> and also make the names more similar to KTF's, and those of user land unit test
> > >
> > > You mean the Googletest/Googlemock expectations/assertions?
> > >
> > > It's a great library (with not so great a name), but unfortunately it
> > > is written in C++, which I think pretty much counts it out here.
>
> Using a similar syntax is a good thing, since it makes it easier for people
> who write tests in user land frameworks to contribute to the kernel tests.
> And if, lets say, someone later comes up with a way to run the KUnit tests in "real"
> user land within Googletest ;-) then less editing would be needed..
>
> > >> frameworks? Also it will make it possible to have functions compiling both with KTF
> > and
> > >> KUnit, facilitating moving code between the two.
> > >
> > > I think that would be cool, but again, I don't think this will be
> > > possible with Googletest/Googlemock.
>
> I was thinking of moves between KUnit tests and KTF tests, kernel code only.
> Some test functions may easily be usable both in a "pure" mocking environment
> and in an integrated setting with hardware/driver/userspace dependencies.
Speaking for KUnit, you are right. I got KUnit working on other
architectures a couple revisions ago (apparently I didn't advertise that
well enough).
> > >>
> > >> Also the string stream facilities of KUnit looks interesting to share.
> > >
> > > I am glad you think so!
> > >
> > > If your biggest concern on my side is test macro names (which I think
> > > is a no-go as I mentioned above), I think we should be in pretty good
> > > shape once you are ready to move forward. Besides, I have a lot more
> > > KUnit patches coming after this: landing this patchset is just the
> > > beginning. So how about we keep moving forward on this patchset?
>
> I think the importance of a well thought through
> test API definition is not to be underestimated
I agree. That is why I am saying that I think we are in good shape if we
are only arguing about the name.
> - the sooner we can unify and establish a common base, the better,
> I think.
Again, I agree. That is what I am trying to do here.
>
> My other concern is, as mentioned earlier, whether UML is really that
> different from just running in a VM wrt debugging support, and that
> there exists a better approach based on automatically generating
> an environment where the test code and the source under test
> can be compiled in a normal user land program. But it seems
> there are enough clients of the UML approach to justify it
> as a lightweight entry. We want to make it easy and inexcusable
> not to test the code, having a low bar of entry is certainly good.
Yep.
> Other than that, I really would need to spend some more time with
> the details on KUnit to verify my so far fairly
> shallow observations!
Are we arguing about anything other than naming schemes here? If that's
it, we can refactor the under the hood stuff later; if we even need to
at all.
Cheers!
next prev parent reply other threads:[~2019-05-14 6:40 UTC|newest]
Thread overview: 131+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-01 23:01 [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 01/17] kunit: test: add KUnit test runner core Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 02/17] kunit: test: add test resource management API Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 03/17] kunit: test: add string_stream a std::stream like string builder Brendan Higgins
2019-05-03 1:26 ` shuah
2019-05-03 4:37 ` Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 04/17] kunit: test: add kunit_stream a std::stream like logger Brendan Higgins
2019-05-02 11:00 ` Greg KH
2019-05-02 20:25 ` Brendan Higgins
2019-05-02 21:18 ` Frank Rowand
2019-05-03 1:50 ` shuah
2019-05-03 5:48 ` Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 05/17] kunit: test: add the concept of expectations Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 06/17] kbuild: enable building KUnit Brendan Higgins
2019-05-10 3:03 ` Masahiro Yamada
2019-05-10 10:27 ` Brendan Higgins
2019-05-10 10:30 ` Masahiro Yamada
2019-05-10 10:33 ` Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 07/17] kunit: test: add initial tests Brendan Higgins
2019-05-02 10:58 ` Greg KH
2019-05-02 20:30 ` Brendan Higgins
2019-05-03 1:27 ` shuah
2019-05-03 5:18 ` Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 08/17] kunit: test: add support for test abort Brendan Higgins
2019-05-03 3:14 ` Logan Gunthorpe
2019-05-03 6:48 ` Brendan Higgins
2019-05-03 12:33 ` Logan Gunthorpe
2019-05-06 8:48 ` Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 09/17] kunit: test: add tests for kunit " Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 10/17] kunit: test: add the concept of assertions Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 11/17] kunit: test: add test managed resource tests Brendan Higgins
2019-05-03 14:34 ` shuah
2019-05-06 9:03 ` Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests Brendan Higgins
2019-05-02 11:02 ` Greg KH
2019-05-02 18:07 ` Brendan Higgins
2019-05-02 21:16 ` Frank Rowand
2019-05-02 23:45 ` Brendan Higgins
2019-05-03 1:45 ` Frank Rowand
2019-05-03 5:36 ` Brendan Higgins
2019-05-03 18:59 ` Frank Rowand
2019-05-03 23:14 ` Brendan Higgins
2019-05-04 10:42 ` Greg KH
2019-05-06 0:19 ` Frank Rowand
2019-05-06 17:43 ` Kees Cook
2019-05-06 21:42 ` Brendan Higgins
2019-05-06 21:39 ` Brendan Higgins
2019-05-07 19:13 ` Tim.Bird
2019-05-03 6:41 ` Greg KH
2019-05-01 23:01 ` [PATCH v2 13/17] kunit: defconfig: add defconfigs for building " Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 14/17] Documentation: kunit: add documentation for KUnit Brendan Higgins
2019-05-09 5:08 ` Randy Dunlap
2019-05-09 17:38 ` Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 15/17] MAINTAINERS: add entry for KUnit the unit testing framework Brendan Higgins
2019-05-03 14:38 ` shuah
2019-05-06 9:18 ` Brendan Higgins
2019-05-01 23:01 ` [PATCH v2 16/17] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec() Brendan Higgins
2019-05-02 11:03 ` Greg KH
2019-05-02 18:14 ` Tim.Bird
2019-05-02 18:45 ` Brendan Higgins
2019-05-03 6:42 ` Greg KH
2019-05-03 23:41 ` Brendan Higgins
2019-05-04 10:40 ` Greg KH
2019-05-01 23:01 ` [PATCH v2 17/17] MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section Brendan Higgins
2019-05-02 10:50 ` [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Greg KH
2019-05-02 11:05 ` Greg KH
2019-05-03 0:41 ` Brendan Higgins
2019-05-02 14:04 ` shuah
2019-05-03 0:44 ` Brendan Higgins
2019-05-03 3:18 ` Logan Gunthorpe
2019-05-07 3:14 ` Frank Rowand
2019-05-07 8:01 ` Greg KH
2019-05-07 15:23 ` shuah
2019-05-09 1:01 ` Frank Rowand
2019-05-07 17:22 ` Theodore Ts'o
2019-05-08 19:17 ` Brendan Higgins
2019-05-09 0:58 ` Frank Rowand
2019-05-09 1:44 ` Theodore Ts'o
2019-05-09 2:18 ` Frank Rowand
2019-05-14 8:22 ` Brendan Higgins
2019-05-09 0:43 ` Frank Rowand
2019-05-09 1:58 ` Theodore Ts'o
2019-05-09 2:13 ` Frank Rowand
2019-05-09 3:20 ` Theodore Ts'o
2019-05-09 11:52 ` Knut Omang
2019-05-09 13:35 ` Theodore Ts'o
2019-05-09 14:48 ` Knut Omang
2019-05-09 17:00 ` Tim.Bird
2019-05-09 17:42 ` Daniel Vetter
2019-05-09 18:12 ` Frank Rowand
2019-05-09 21:42 ` Theodore Ts'o
2019-05-09 22:20 ` Logan Gunthorpe
2019-05-09 23:30 ` Theodore Ts'o
2019-05-09 23:40 ` Logan Gunthorpe
2019-05-10 4:47 ` Theodore Ts'o
2019-05-10 5:18 ` Frank Rowand
2019-05-10 5:48 ` Knut Omang
2019-05-10 8:12 ` Daniel Vetter
2019-05-10 10:23 ` Brendan Higgins
2019-05-10 12:12 ` Knut Omang
2019-05-10 20:54 ` Brendan Higgins
2019-05-10 22:18 ` Frank Rowand
2019-05-11 6:17 ` Knut Omang
2019-05-14 6:39 ` Brendan Higgins [this message]
2019-05-10 21:59 ` Frank Rowand
2019-05-11 6:43 ` Knut Omang
2019-05-14 8:00 ` Brendan Higgins
2019-05-10 11:36 ` Knut Omang
2019-05-10 16:17 ` Logan Gunthorpe
2019-05-10 22:13 ` Frank Rowand
2019-05-14 8:38 ` Brendan Higgins
2019-05-15 0:14 ` Frank Rowand
2019-05-15 0:26 ` Logan Gunthorpe
2019-05-10 21:52 ` Frank Rowand
2019-05-14 20:54 ` Brendan Higgins
2019-05-10 21:12 ` Frank Rowand
2019-05-11 17:33 ` Theodore Ts'o
2019-05-13 14:44 ` Daniel Vetter
2019-05-14 6:04 ` Brendan Higgins
2019-05-14 12:05 ` Daniel Vetter
2019-05-14 18:36 ` Brendan Higgins
2019-05-15 7:41 ` Daniel Vetter
2019-05-22 21:38 ` Brendan Higgins
2019-05-23 8:40 ` Daniel Vetter
2019-05-15 0:26 ` Frank Rowand
2019-05-15 4:28 ` Theodore Ts'o
2019-05-10 5:11 ` Frank Rowand
2019-05-10 10:43 ` Theodore Ts'o
2019-05-10 21:05 ` Frank Rowand
2019-05-09 15:19 ` Masahiro Yamada
2019-05-10 10:25 ` 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=20190514063953.GB181462@google.com \
--to=brendanhiggins@google.com \
--cc=Alexander.Levin@microsoft.com \
--cc=Tim.Bird@sony.com \
--cc=amir73il@gmail.com \
--cc=dan.carpenter@oracle.com \
--cc=dan.j.williams@intel.com \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jdike@addtoit.com \
--cc=joel@jms.id.au \
--cc=julia.lawall@lip6.fr \
--cc=keescook@google.com \
--cc=khilman@baylibre.com \
--cc=kieran.bingham@ideasonboard.com \
--cc=knut.omang@oracle.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-um@lists.infradead.org \
--cc=logang@deltatee.com \
--cc=mcgrof@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=pmladek@suse.com \
--cc=richard@nod.at \
--cc=rientjes@google.com \
--cc=robh@kernel.org \
--cc=rostedt@goodmis.org \
--cc=sboyd@kernel.org \
--cc=shuah@kernel.org \
--cc=tytso@mit.edu \
--cc=wfg@linux.intel.com \
/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).