From: brendanhiggins at google.com (Brendan Higgins) Subject: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests Date: Thu, 2 May 2019 22:36:03 -0700 [thread overview] Message-ID: <CAFd5g45RYm+zfdJXnyp2KZZH5ojfOzy++aq+4zBeE5VDu6WgEw@mail.gmail.com> (raw) In-Reply-To: <1a5f3c44-9fa9-d423-66bf-45255a90c468@gmail.com> On Thu, May 2, 2019 at 6:45 PM Frank Rowand <frowand.list at gmail.com> wrote: > > On 5/2/19 4:45 PM, Brendan Higgins wrote: > > On Thu, May 2, 2019 at 2:16 PM Frank Rowand <frowand.list at gmail.com> wrote: > >> > >> On 5/2/19 11:07 AM, Brendan Higgins wrote: > >>> On Thu, May 2, 2019 at 4:02 AM Greg KH <gregkh at linuxfoundation.org> wrote: > >>>> > >>>> On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote: > >>>>> From: Felix Guo <felixguoxiuping at gmail.com> > >>>>> > >>>>> The ultimate goal is to create minimal isolated test binaries; in the > >>>>> meantime we are using UML to provide the infrastructure to run tests, so > >>>>> define an abstract way to configure and run tests that allow us to > >>>>> change the context in which tests are built without affecting the user. > >>>>> This also makes pretty and dynamic error reporting, and a lot of other > >>>>> nice features easier. > >>>>> > >>>>> kunit_config.py: > >>>>> - parse .config and Kconfig files. > >>>>> > >>>>> kunit_kernel.py: provides helper functions to: > >>>>> - configure the kernel using kunitconfig. > >>>>> - build the kernel with the appropriate configuration. > >>>>> - provide function to invoke the kernel and stream the output back. > >>>>> > >>>>> Signed-off-by: Felix Guo <felixguoxiuping at gmail.com> > >>>>> Signed-off-by: Brendan Higgins <brendanhiggins at google.com> > >>>> > >>>> Ah, here's probably my answer to my previous logging format question, > >>>> right? What's the chance that these wrappers output stuff in a standard > >>>> format that test-framework-tools can already parse? :) > > > > To be clear, the test-framework-tools format we are talking about is > > TAP13[1], correct? > > I'm not sure what the test community prefers for a format. I'll let them > jump in and debate that question. > > > > > > My understanding is that is what kselftest is being converted to use. > > > >>> > >>> It should be pretty easy to do. I had some patches that pack up the > >>> results into a serialized format for a presubmit service; it should be > >>> pretty straightforward to take the same logic and just change the > >>> output format. > >> > >> When examining and trying out the previous versions of the patch I found > >> the wrappers useful to provide information about how to control and use > >> the tests, but I had no interest in using the scripts as they do not > >> fit in with my personal environment and workflow. > >> > >> In the previous versions of the patch, these helper scripts are optional, > >> which is good for my use case. If the helper scripts are required to > > > > They are still optional. > > > >> get the data into the proper format then the scripts are not quite so > >> optional, they become the expected environment. I think the proper > >> format should exist without the helper scripts. > > > > That's a good point. A couple things, > > > > First off, supporting TAP13, either in the kernel or the wrapper > > script is not hard, but I don't think that is the real issue that you > > raise. > > > > If your only concern is that you will always be able to have human > > readable KUnit results printed to the kernel log, that is a guarantee > > I feel comfortable making. Beyond that, I think it is going to take a > > long while before I would feel comfortable guaranteeing anything about > > how will KUnit work, what kind of data it will want to expose, and how > > it will be organized. I think the wrapper script provides a nice > > facade that I can maintain, can mediate between the implementation > > details and the user, and can mediate between the implementation > > details and other pieces of software that might want to consume > > results. > > > > [1] https://testanything.org/tap-version-13-specification.html > > My concern is based on a focus on my little part of the world > (which in _previous_ versions of the patch series was the devicetree > unittest.c tests being converted to use the kunit infrastructure). > If I step back and think of the entire kernel globally I may end > up with a different conclusion - but I'm going to remain myopic > for this email. > > I want the test results to be usable by me and my fellow > developers. I prefer that the test results be easily accessible > (current printk() implementation means that kunit messages are > just as accessible as the current unittest.c printk() output). > If the printk() output needs to be filtered through a script > to generate the actual test results then that is sub-optimal > to me. It is one more step added to my workflow. And > potentially with an embedded target a major pain to get a > data file (the kernel log file) transferred from a target > to my development host. That's fair. If that is indeed your only concern, then I don't think the wrapper script will ever be an issue for you. You will always be able to execute a given test the old fashioned/manual way, and the wrapper script only summarizes results, it does not change the contents. > > I want a reported test failure to be easy to trace back to the > point in the source where the failure is reported. With printk() > the search is a simple grep for the failure message. If the > failure message has been processed by a script, and then the > failure reported to me in an email, then I may have to look > at the script to reverse engineer how the original failure > message was transformed into the message that was reported > to me in the email. Then I search for the point in the > source where the failure is reported. So a basic task has > just become more difficult and time consuming. That seems to be a valid concern. I would reiterate that you shouldn't be concerned by any processing done by the wrapper script itself, but the reality is that depending on what happens with automated testing/presubmit/CI other people might end up parsing and transforming test results - it might happen, it might not. I currently have a CI system set up for KUnit on my public repo that I don't think you would be offended by, but I don't know what we are going to do when it comes time to integrate with existing upstream CI systems. In anycase, I don't think that either sticking with or doing away with the wrapper script is going to have any long term bearing on what happens in this regard. Cheers
WARNING: multiple messages have this Message-ID (diff)
From: brendanhiggins@google.com (Brendan Higgins) Subject: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests Date: Thu, 2 May 2019 22:36:03 -0700 [thread overview] Message-ID: <CAFd5g45RYm+zfdJXnyp2KZZH5ojfOzy++aq+4zBeE5VDu6WgEw@mail.gmail.com> (raw) Message-ID: <20190503053603.wMkJFLmgTrcScIgXS4h9b7GI6nkWOxudUxtlhO-ptxc@z> (raw) In-Reply-To: <1a5f3c44-9fa9-d423-66bf-45255a90c468@gmail.com> On Thu, May 2, 2019@6:45 PM Frank Rowand <frowand.list@gmail.com> wrote: > > On 5/2/19 4:45 PM, Brendan Higgins wrote: > > On Thu, May 2, 2019@2:16 PM Frank Rowand <frowand.list@gmail.com> wrote: > >> > >> On 5/2/19 11:07 AM, Brendan Higgins wrote: > >>> On Thu, May 2, 2019@4:02 AM Greg KH <gregkh@linuxfoundation.org> wrote: > >>>> > >>>> On Wed, May 01, 2019@04:01:21PM -0700, Brendan Higgins wrote: > >>>>> From: Felix Guo <felixguoxiuping at gmail.com> > >>>>> > >>>>> The ultimate goal is to create minimal isolated test binaries; in the > >>>>> meantime we are using UML to provide the infrastructure to run tests, so > >>>>> define an abstract way to configure and run tests that allow us to > >>>>> change the context in which tests are built without affecting the user. > >>>>> This also makes pretty and dynamic error reporting, and a lot of other > >>>>> nice features easier. > >>>>> > >>>>> kunit_config.py: > >>>>> - parse .config and Kconfig files. > >>>>> > >>>>> kunit_kernel.py: provides helper functions to: > >>>>> - configure the kernel using kunitconfig. > >>>>> - build the kernel with the appropriate configuration. > >>>>> - provide function to invoke the kernel and stream the output back. > >>>>> > >>>>> Signed-off-by: Felix Guo <felixguoxiuping at gmail.com> > >>>>> Signed-off-by: Brendan Higgins <brendanhiggins at google.com> > >>>> > >>>> Ah, here's probably my answer to my previous logging format question, > >>>> right? What's the chance that these wrappers output stuff in a standard > >>>> format that test-framework-tools can already parse? :) > > > > To be clear, the test-framework-tools format we are talking about is > > TAP13[1], correct? > > I'm not sure what the test community prefers for a format. I'll let them > jump in and debate that question. > > > > > > My understanding is that is what kselftest is being converted to use. > > > >>> > >>> It should be pretty easy to do. I had some patches that pack up the > >>> results into a serialized format for a presubmit service; it should be > >>> pretty straightforward to take the same logic and just change the > >>> output format. > >> > >> When examining and trying out the previous versions of the patch I found > >> the wrappers useful to provide information about how to control and use > >> the tests, but I had no interest in using the scripts as they do not > >> fit in with my personal environment and workflow. > >> > >> In the previous versions of the patch, these helper scripts are optional, > >> which is good for my use case. If the helper scripts are required to > > > > They are still optional. > > > >> get the data into the proper format then the scripts are not quite so > >> optional, they become the expected environment. I think the proper > >> format should exist without the helper scripts. > > > > That's a good point. A couple things, > > > > First off, supporting TAP13, either in the kernel or the wrapper > > script is not hard, but I don't think that is the real issue that you > > raise. > > > > If your only concern is that you will always be able to have human > > readable KUnit results printed to the kernel log, that is a guarantee > > I feel comfortable making. Beyond that, I think it is going to take a > > long while before I would feel comfortable guaranteeing anything about > > how will KUnit work, what kind of data it will want to expose, and how > > it will be organized. I think the wrapper script provides a nice > > facade that I can maintain, can mediate between the implementation > > details and the user, and can mediate between the implementation > > details and other pieces of software that might want to consume > > results. > > > > [1] https://testanything.org/tap-version-13-specification.html > > My concern is based on a focus on my little part of the world > (which in _previous_ versions of the patch series was the devicetree > unittest.c tests being converted to use the kunit infrastructure). > If I step back and think of the entire kernel globally I may end > up with a different conclusion - but I'm going to remain myopic > for this email. > > I want the test results to be usable by me and my fellow > developers. I prefer that the test results be easily accessible > (current printk() implementation means that kunit messages are > just as accessible as the current unittest.c printk() output). > If the printk() output needs to be filtered through a script > to generate the actual test results then that is sub-optimal > to me. It is one more step added to my workflow. And > potentially with an embedded target a major pain to get a > data file (the kernel log file) transferred from a target > to my development host. That's fair. If that is indeed your only concern, then I don't think the wrapper script will ever be an issue for you. You will always be able to execute a given test the old fashioned/manual way, and the wrapper script only summarizes results, it does not change the contents. > > I want a reported test failure to be easy to trace back to the > point in the source where the failure is reported. With printk() > the search is a simple grep for the failure message. If the > failure message has been processed by a script, and then the > failure reported to me in an email, then I may have to look > at the script to reverse engineer how the original failure > message was transformed into the message that was reported > to me in the email. Then I search for the point in the > source where the failure is reported. So a basic task has > just become more difficult and time consuming. That seems to be a valid concern. I would reiterate that you shouldn't be concerned by any processing done by the wrapper script itself, but the reality is that depending on what happens with automated testing/presubmit/CI other people might end up parsing and transforming test results - it might happen, it might not. I currently have a CI system set up for KUnit on my public repo that I don't think you would be offended by, but I don't know what we are going to do when it comes time to integrate with existing upstream CI systems. In anycase, I don't think that either sticking with or doing away with the wrapper script is going to have any long term bearing on what happens in this regard. Cheers
next prev parent reply other threads:[~2019-05-03 5:36 UTC|newest] Thread overview: 262+ 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 brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-01 23:01 ` [PATCH v2 01/17] kunit: test: add KUnit test runner core brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-01 23:01 ` [PATCH v2 02/17] kunit: test: add test resource management API brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-01 23:01 ` [PATCH v2 03/17] kunit: test: add string_stream a std::stream like string builder brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-03 1:26 ` shuah 2019-05-03 1:26 ` shuah 2019-05-03 4:37 ` brendanhiggins 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 brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-02 11:00 ` gregkh 2019-05-02 11:00 ` Greg KH 2019-05-02 20:25 ` brendanhiggins 2019-05-02 20:25 ` Brendan Higgins 2019-05-02 21:18 ` frowand.list 2019-05-02 21:18 ` Frank Rowand 2019-05-03 1:50 ` shuah 2019-05-03 1:50 ` shuah 2019-05-03 5:48 ` brendanhiggins 2019-05-03 5:48 ` Brendan Higgins 2019-05-01 23:01 ` [PATCH v2 05/17] kunit: test: add the concept of expectations brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-01 23:01 ` [PATCH v2 06/17] kbuild: enable building KUnit brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-10 3:03 ` yamada.masahiro 2019-05-10 3:03 ` Masahiro Yamada 2019-05-10 10:27 ` brendanhiggins 2019-05-10 10:27 ` Brendan Higgins 2019-05-10 10:30 ` yamada.masahiro 2019-05-10 10:30 ` Masahiro Yamada 2019-05-10 10:33 ` brendanhiggins 2019-05-10 10:33 ` Brendan Higgins 2019-05-01 23:01 ` [PATCH v2 07/17] kunit: test: add initial tests brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-02 10:58 ` gregkh 2019-05-02 10:58 ` Greg KH 2019-05-02 20:30 ` brendanhiggins 2019-05-02 20:30 ` Brendan Higgins 2019-05-03 1:27 ` shuah 2019-05-03 1:27 ` shuah 2019-05-03 5:18 ` brendanhiggins 2019-05-03 5:18 ` Brendan Higgins 2019-05-01 23:01 ` [PATCH v2 08/17] kunit: test: add support for test abort brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-03 3:14 ` logang 2019-05-03 3:14 ` Logan Gunthorpe 2019-05-03 6:48 ` brendanhiggins 2019-05-03 6:48 ` Brendan Higgins 2019-05-03 12:33 ` logang 2019-05-03 12:33 ` Logan Gunthorpe 2019-05-06 8:48 ` brendanhiggins 2019-05-06 8:48 ` Brendan Higgins 2019-05-01 23:01 ` [PATCH v2 09/17] kunit: test: add tests for kunit " brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-01 23:01 ` [PATCH v2 10/17] kunit: test: add the concept of assertions brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-01 23:01 ` [PATCH v2 11/17] kunit: test: add test managed resource tests brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-03 14:34 ` shuah 2019-05-03 14:34 ` shuah 2019-05-06 9:03 ` brendanhiggins 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 brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-02 11:02 ` gregkh 2019-05-02 11:02 ` Greg KH 2019-05-02 18:07 ` brendanhiggins 2019-05-02 18:07 ` Brendan Higgins 2019-05-02 21:16 ` frowand.list 2019-05-02 21:16 ` Frank Rowand 2019-05-02 23:45 ` brendanhiggins 2019-05-02 23:45 ` Brendan Higgins 2019-05-03 1:45 ` frowand.list 2019-05-03 1:45 ` Frank Rowand 2019-05-03 5:36 ` brendanhiggins [this message] 2019-05-03 5:36 ` Brendan Higgins 2019-05-03 18:59 ` frowand.list 2019-05-03 18:59 ` Frank Rowand 2019-05-03 23:14 ` brendanhiggins 2019-05-03 23:14 ` Brendan Higgins 2019-05-04 10:42 ` gregkh 2019-05-04 10:42 ` Greg KH 2019-05-06 0:19 ` frowand.list 2019-05-06 0:19 ` Frank Rowand 2019-05-06 17:43 ` keescook 2019-05-06 17:43 ` Kees Cook 2019-05-06 21:42 ` brendanhiggins 2019-05-06 21:42 ` Brendan Higgins 2019-05-06 21:39 ` brendanhiggins 2019-05-06 21:39 ` Brendan Higgins 2019-05-07 19:13 ` Tim.Bird 2019-05-07 19:13 ` Tim.Bird 2019-05-03 6:41 ` gregkh 2019-05-03 6:41 ` Greg KH 2019-05-01 23:01 ` [PATCH v2 13/17] kunit: defconfig: add defconfigs for building " brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-01 23:01 ` [PATCH v2 14/17] Documentation: kunit: add documentation for KUnit brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-09 5:08 ` rdunlap 2019-05-09 5:08 ` Randy Dunlap 2019-05-09 17:38 ` brendanhiggins 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 brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-03 14:38 ` shuah 2019-05-03 14:38 ` shuah 2019-05-06 9:18 ` brendanhiggins 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() brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-02 11:03 ` gregkh 2019-05-02 11:03 ` Greg KH 2019-05-02 18:14 ` Tim.Bird 2019-05-02 18:14 ` Tim.Bird 2019-05-02 18:45 ` brendanhiggins 2019-05-02 18:45 ` Brendan Higgins 2019-05-03 6:42 ` gregkh 2019-05-03 6:42 ` Greg KH 2019-05-03 23:41 ` brendanhiggins 2019-05-03 23:41 ` Brendan Higgins 2019-05-04 10:40 ` gregkh 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 brendanhiggins 2019-05-01 23:01 ` Brendan Higgins 2019-05-02 10:50 ` [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework gregkh 2019-05-02 10:50 ` Greg KH 2019-05-02 11:05 ` gregkh 2019-05-02 11:05 ` Greg KH 2019-05-03 0:41 ` brendanhiggins 2019-05-03 0:41 ` Brendan Higgins 2019-05-02 14:04 ` shuah 2019-05-02 14:04 ` shuah 2019-05-03 0:44 ` brendanhiggins 2019-05-03 0:44 ` Brendan Higgins 2019-05-03 3:18 ` logang 2019-05-03 3:18 ` Logan Gunthorpe 2019-05-07 3:14 ` frowand.list 2019-05-07 3:14 ` Frank Rowand 2019-05-07 8:01 ` gregkh 2019-05-07 8:01 ` Greg KH 2019-05-07 15:23 ` shuah 2019-05-07 15:23 ` shuah 2019-05-09 1:01 ` frowand.list 2019-05-09 1:01 ` Frank Rowand 2019-05-07 17:22 ` tytso 2019-05-07 17:22 ` Theodore Ts'o 2019-05-08 19:17 ` brendanhiggins 2019-05-08 19:17 ` Brendan Higgins 2019-05-09 0:58 ` frowand.list 2019-05-09 0:58 ` Frank Rowand 2019-05-09 1:44 ` tytso 2019-05-09 1:44 ` Theodore Ts'o 2019-05-09 2:18 ` frowand.list 2019-05-09 2:18 ` Frank Rowand 2019-05-14 8:22 ` brendanhiggins 2019-05-14 8:22 ` Brendan Higgins 2019-05-09 0:43 ` frowand.list 2019-05-09 0:43 ` Frank Rowand 2019-05-09 1:58 ` tytso 2019-05-09 1:58 ` Theodore Ts'o 2019-05-09 2:13 ` frowand.list 2019-05-09 2:13 ` Frank Rowand 2019-05-09 3:20 ` tytso 2019-05-09 3:20 ` Theodore Ts'o 2019-05-09 11:52 ` knut.omang 2019-05-09 11:52 ` Knut Omang 2019-05-09 13:35 ` tytso 2019-05-09 13:35 ` Theodore Ts'o 2019-05-09 14:48 ` knut.omang 2019-05-09 14:48 ` Knut Omang 2019-05-09 17:00 ` Tim.Bird 2019-05-09 17:00 ` Tim.Bird 2019-05-09 17:42 ` daniel 2019-05-09 17:42 ` Daniel Vetter 2019-05-09 18:12 ` frowand.list 2019-05-09 18:12 ` Frank Rowand 2019-05-09 21:42 ` tytso 2019-05-09 21:42 ` Theodore Ts'o 2019-05-09 22:20 ` logang 2019-05-09 22:20 ` Logan Gunthorpe 2019-05-09 23:30 ` tytso 2019-05-09 23:30 ` Theodore Ts'o 2019-05-09 23:40 ` logang 2019-05-09 23:40 ` Logan Gunthorpe 2019-05-10 4:47 ` tytso 2019-05-10 4:47 ` Theodore Ts'o 2019-05-10 5:18 ` frowand.list 2019-05-10 5:18 ` Frank Rowand 2019-05-10 5:48 ` knut.omang 2019-05-10 5:48 ` Knut Omang 2019-05-10 8:12 ` daniel 2019-05-10 8:12 ` Daniel Vetter 2019-05-10 10:23 ` brendanhiggins 2019-05-10 10:23 ` Brendan Higgins 2019-05-10 12:12 ` knut.omang 2019-05-10 12:12 ` Knut Omang 2019-05-10 20:54 ` brendanhiggins 2019-05-10 20:54 ` Brendan Higgins 2019-05-10 22:18 ` frowand.list 2019-05-10 22:18 ` Frank Rowand 2019-05-11 6:17 ` knut.omang 2019-05-11 6:17 ` Knut Omang 2019-05-14 6:39 ` brendanhiggins 2019-05-14 6:39 ` Brendan Higgins 2019-05-10 21:59 ` frowand.list 2019-05-10 21:59 ` Frank Rowand 2019-05-11 6:43 ` knut.omang 2019-05-11 6:43 ` Knut Omang 2019-05-14 8:00 ` brendanhiggins 2019-05-14 8:00 ` Brendan Higgins 2019-05-10 11:36 ` knut.omang 2019-05-10 11:36 ` Knut Omang 2019-05-10 16:17 ` logang 2019-05-10 16:17 ` Logan Gunthorpe 2019-05-10 22:13 ` frowand.list 2019-05-10 22:13 ` Frank Rowand 2019-05-14 8:38 ` brendanhiggins 2019-05-14 8:38 ` Brendan Higgins 2019-05-15 0:14 ` frowand.list 2019-05-15 0:14 ` Frank Rowand 2019-05-15 0:26 ` logang 2019-05-15 0:26 ` Logan Gunthorpe 2019-05-10 21:52 ` frowand.list 2019-05-10 21:52 ` Frank Rowand 2019-05-14 20:54 ` brendanhiggins 2019-05-14 20:54 ` Brendan Higgins 2019-05-10 21:12 ` frowand.list 2019-05-10 21:12 ` Frank Rowand 2019-05-11 17:33 ` tytso 2019-05-11 17:33 ` Theodore Ts'o 2019-05-13 14:44 ` daniel 2019-05-13 14:44 ` Daniel Vetter 2019-05-14 6:04 ` brendanhiggins 2019-05-14 6:04 ` Brendan Higgins 2019-05-14 12:05 ` daniel 2019-05-14 12:05 ` Daniel Vetter 2019-05-14 18:36 ` brendanhiggins 2019-05-14 18:36 ` Brendan Higgins 2019-05-15 7:41 ` daniel 2019-05-15 7:41 ` Daniel Vetter 2019-05-22 21:38 ` brendanhiggins 2019-05-22 21:38 ` Brendan Higgins 2019-05-23 8:40 ` daniel 2019-05-23 8:40 ` Daniel Vetter 2019-05-15 0:26 ` frowand.list 2019-05-15 0:26 ` Frank Rowand 2019-05-15 4:28 ` tytso 2019-05-15 4:28 ` Theodore Ts'o 2019-05-10 5:11 ` frowand.list 2019-05-10 5:11 ` Frank Rowand 2019-05-10 10:43 ` tytso 2019-05-10 10:43 ` Theodore Ts'o 2019-05-10 21:05 ` frowand.list 2019-05-10 21:05 ` Frank Rowand 2019-05-09 15:19 ` yamada.masahiro 2019-05-09 15:19 ` Masahiro Yamada 2019-05-10 10:25 ` brendanhiggins 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=CAFd5g45RYm+zfdJXnyp2KZZH5ojfOzy++aq+4zBeE5VDu6WgEw@mail.gmail.com \ --to=linux-kselftest@vger.kernel.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: linkBe 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).