From: brendanhiggins at google.com (Brendan Higgins) Subject: [RFC v3 18/19] of: unittest: split out a couple of test cases from unittest Date: Thu, 21 Mar 2019 18:30:38 -0700 [thread overview] Message-ID: <CAFd5g448xQLOJwVYU5Zmu4+OPWuboiWZPhBvK6au8Pgm5B9haQ@mail.gmail.com> (raw) In-Reply-To: <bb5bcd3d-a09a-cfbe-c7fa-16e5eb75b0e4@gmail.com> On Thu, Mar 21, 2019 at 5:22 PM Frank Rowand <frowand.list at gmail.com> wrote: > > On 2/27/19 7:52 PM, Brendan Higgins wrote: > > On Wed, Feb 20, 2019 at 12:45 PM Frank Rowand <frowand.list at gmail.com> wrote: > >> > >> On 2/18/19 2:25 PM, Frank Rowand wrote: > >>> On 2/15/19 2:56 AM, Brendan Higgins wrote: > >>>> On Thu, Feb 14, 2019 at 6:05 PM Frank Rowand <frowand.list at gmail.com> wrote: > >>>>> > >>>>> On 2/14/19 4:56 PM, Brendan Higgins wrote: > >>>>>> On Thu, Feb 14, 2019 at 3:57 PM Frank Rowand <frowand.list at gmail.com> wrote: > >>>>>>> > >>>>>>> On 12/5/18 3:54 PM, Brendan Higgins wrote: > >>>>>>>> On Tue, Dec 4, 2018 at 2:58 AM Frank Rowand <frowand.list at gmail.com> wrote: < snip > > >> > >> In the base version, the order of execution of the test code requires > >> bouncing back and forth between the test functions and the coding of > >> of_test_find_node_by_name_cases[]. > > > > You shouldn't need to bounce back and forth because the order in which > > the tests run shouldn't matter. > > If one can't guarantee total independence of all of the tests, with no > side effects, then yes. But that is not my world. To make that > guarantee, I would need to be able to run just a single test in an > entire test run. > > I actually want to make side effects possible. Whether from other > tests or from live kernel code that is accessing the live devicetree. > Any extra stress makes me happier. > > I forget the exact term that has been tossed around, but to me the > devicetree unittests are more like system validation, release tests, > acceptance tests, and stress tests. Not unit tests in the philosophy > of KUnit. Ah, I understand. I thought that they were actually trying to be unit tests; that pretty much voids this discussion then. Integration tests and end to end tests are valuable as long as that is actually what you are trying to do. > > I do see the value of pure unit tests, and there are rare times that > my devicetree use case might be better served by that approach. But > if so, it is very easy for me to add a simple pure test when debugging. > My general use case does not map onto this model. Why do you think it is rare that you would actually want unit tests? I mean, if you don't get much code churn, then maybe it's not going to provide you a ton of value to immediately go and write a bunch of unit tests right now, but I can't think of a single time where it's hurt. Unit tests, from my experience, are usually the easiest tests to maintain, and the most helpful when I am developing. Maybe I need to understand your use case better. > > > >> > >> In the frank version the order of execution of the test code is obvious. > > > > So I know we were arguing before over whether order *does* matter in > > some of the other test cases (none in the example that you or I > > posted), but wouldn't it be better if the order of execution didn't > > matter? If you don't allow a user to depend on the execution of test > > cases, then arguably these test case dependencies would never form and > > the order wouldn't matter. > > Reality intrudes. Order does matter. > > > >> > >> It is possible that a test function could be left out of > >> of_test_find_node_by_name_cases[], in error. This will result in a compile > >> warning (I think warning instead of error, but I have not verified that) > >> so it might be caught or it might be overlooked. > >> > >> The base version is 265 lines. The frank version is 208 lines, 57 lines > >> less. Less is better. > > > > I agree that less is better, but there are different kinds of less to > > consider. I prefer less logic in a function to fewer lines overall. > > > > It seems we are in agreement that test cases should be small and > > simple, so I won't dwell on that point any longer. I agree that the > > As a general guide for simple unit tests, sure. > > For my case, no. Reality intrudes. > > KUnit has a nice architectural view of what a unit test should be. Cool, I am glad you think so! That actually means a lot to me. I was afraid I wasn't conveying the idea properly and that was the root of this debate. > > The existing devicetree "unittests" are not such unit tests. They > simply share the same name. > > The devicetree unittests do not fit into a clean: > - initialize > - do one test > - clean up > model. > > Trying to force them into that model will not work. The initialize > is not a simple, easy to decompose thing. And trying to decompose > it can actually make the code more complex and messier. > > Clean up can NOT occur, because part of my test validation is looking > at the state of the device tree after the tests complete, viewed > through the /proc/device-tree/ interface. > Again, if they are not actually intended to be unit tests, then I think that is fine. < snip > > > Compare the test cases for adding of_test_dynamic_basic, > > of_test_dynamic_add_existing_property, > > of_test_dynamic_modify_existing_property, and > > of_test_dynamic_modify_non_existent_property to the originals. My > > version is much longer overall, but I think is still much easier to > > understand. I can say from when I was trying to split this up in the > > first place, it was not obvious what properties were expected to be > > populated as a precondition for a given test case (except the first > > one of course). Whereas, in my version, it is immediately obvious what > > the preconditions are for a test case. I think you can apply this same > > logic to the examples you provided, in frank version, I don't > > immediately know if one test cases does something that is a > > precondition for another test case. > > Yes, that is a real problem in the current code, but easily fixed > with comments. I think it is best when you don't need comments, but in this case, I think I have to agree with you. > > > > My version also makes it easier to run a test case entirely by itself > > which is really valuable for debugging purposes. A common thing that > > happens when you have lots of unit tests is something breaks and lots > > of tests fail. If the test cases are good, there should be just a > > couple (ideally one) test cases that directly assert the violated > > property; those are the test cases you actually want to focus on, the > > rest are noise for the purposes of that breakage. In my version, it is > > much easier to turn off the test cases that you don't care about and > > then focus in on the ones that exercise the violated property. > > > > Now I know that, hermeticity especially, but other features as well > > (test suite summary, error on unused test case function, etc) are not > > actually in KUnit as it is under consideration here. Maybe it would be > > best to save these last two patches (18/19, and 19/19) until I have > > these other features checked in and reconsider them then? > > Thanks for leaving 18/19 and 19/19 off in v4. Sure, no problem. It was pretty clear that it was a waste of both of our times to continue discussing those at this juncture. :-) Do you still want me to try to convert the DT not-exactly-unittest to KUnit? I would kind of prefer (I don't feel *super* strongly about the matter) we don't call it that since I was intending for it to be the flagship initial example, but I certainly don't mind trying to clean this patch up to get it up to snuff. It's really just a question of whether it is worth it to you. < snip > Cheers!
WARNING: multiple messages have this Message-ID (diff)
From: brendanhiggins@google.com (Brendan Higgins) Subject: [RFC v3 18/19] of: unittest: split out a couple of test cases from unittest Date: Thu, 21 Mar 2019 18:30:38 -0700 [thread overview] Message-ID: <CAFd5g448xQLOJwVYU5Zmu4+OPWuboiWZPhBvK6au8Pgm5B9haQ@mail.gmail.com> (raw) Message-ID: <20190322013038.5LirTmqW132ETwQ3u4zJk4tNkTwmkYKLHCrsX3a2j0I@z> (raw) In-Reply-To: <bb5bcd3d-a09a-cfbe-c7fa-16e5eb75b0e4@gmail.com> On Thu, Mar 21, 2019@5:22 PM Frank Rowand <frowand.list@gmail.com> wrote: > > On 2/27/19 7:52 PM, Brendan Higgins wrote: > > On Wed, Feb 20, 2019@12:45 PM Frank Rowand <frowand.list@gmail.com> wrote: > >> > >> On 2/18/19 2:25 PM, Frank Rowand wrote: > >>> On 2/15/19 2:56 AM, Brendan Higgins wrote: > >>>> On Thu, Feb 14, 2019@6:05 PM Frank Rowand <frowand.list@gmail.com> wrote: > >>>>> > >>>>> On 2/14/19 4:56 PM, Brendan Higgins wrote: > >>>>>> On Thu, Feb 14, 2019@3:57 PM Frank Rowand <frowand.list@gmail.com> wrote: > >>>>>>> > >>>>>>> On 12/5/18 3:54 PM, Brendan Higgins wrote: > >>>>>>>> On Tue, Dec 4, 2018@2:58 AM Frank Rowand <frowand.list@gmail.com> wrote: < snip > > >> > >> In the base version, the order of execution of the test code requires > >> bouncing back and forth between the test functions and the coding of > >> of_test_find_node_by_name_cases[]. > > > > You shouldn't need to bounce back and forth because the order in which > > the tests run shouldn't matter. > > If one can't guarantee total independence of all of the tests, with no > side effects, then yes. But that is not my world. To make that > guarantee, I would need to be able to run just a single test in an > entire test run. > > I actually want to make side effects possible. Whether from other > tests or from live kernel code that is accessing the live devicetree. > Any extra stress makes me happier. > > I forget the exact term that has been tossed around, but to me the > devicetree unittests are more like system validation, release tests, > acceptance tests, and stress tests. Not unit tests in the philosophy > of KUnit. Ah, I understand. I thought that they were actually trying to be unit tests; that pretty much voids this discussion then. Integration tests and end to end tests are valuable as long as that is actually what you are trying to do. > > I do see the value of pure unit tests, and there are rare times that > my devicetree use case might be better served by that approach. But > if so, it is very easy for me to add a simple pure test when debugging. > My general use case does not map onto this model. Why do you think it is rare that you would actually want unit tests? I mean, if you don't get much code churn, then maybe it's not going to provide you a ton of value to immediately go and write a bunch of unit tests right now, but I can't think of a single time where it's hurt. Unit tests, from my experience, are usually the easiest tests to maintain, and the most helpful when I am developing. Maybe I need to understand your use case better. > > > >> > >> In the frank version the order of execution of the test code is obvious. > > > > So I know we were arguing before over whether order *does* matter in > > some of the other test cases (none in the example that you or I > > posted), but wouldn't it be better if the order of execution didn't > > matter? If you don't allow a user to depend on the execution of test > > cases, then arguably these test case dependencies would never form and > > the order wouldn't matter. > > Reality intrudes. Order does matter. > > > >> > >> It is possible that a test function could be left out of > >> of_test_find_node_by_name_cases[], in error. This will result in a compile > >> warning (I think warning instead of error, but I have not verified that) > >> so it might be caught or it might be overlooked. > >> > >> The base version is 265 lines. The frank version is 208 lines, 57 lines > >> less. Less is better. > > > > I agree that less is better, but there are different kinds of less to > > consider. I prefer less logic in a function to fewer lines overall. > > > > It seems we are in agreement that test cases should be small and > > simple, so I won't dwell on that point any longer. I agree that the > > As a general guide for simple unit tests, sure. > > For my case, no. Reality intrudes. > > KUnit has a nice architectural view of what a unit test should be. Cool, I am glad you think so! That actually means a lot to me. I was afraid I wasn't conveying the idea properly and that was the root of this debate. > > The existing devicetree "unittests" are not such unit tests. They > simply share the same name. > > The devicetree unittests do not fit into a clean: > - initialize > - do one test > - clean up > model. > > Trying to force them into that model will not work. The initialize > is not a simple, easy to decompose thing. And trying to decompose > it can actually make the code more complex and messier. > > Clean up can NOT occur, because part of my test validation is looking > at the state of the device tree after the tests complete, viewed > through the /proc/device-tree/ interface. > Again, if they are not actually intended to be unit tests, then I think that is fine. < snip > > > Compare the test cases for adding of_test_dynamic_basic, > > of_test_dynamic_add_existing_property, > > of_test_dynamic_modify_existing_property, and > > of_test_dynamic_modify_non_existent_property to the originals. My > > version is much longer overall, but I think is still much easier to > > understand. I can say from when I was trying to split this up in the > > first place, it was not obvious what properties were expected to be > > populated as a precondition for a given test case (except the first > > one of course). Whereas, in my version, it is immediately obvious what > > the preconditions are for a test case. I think you can apply this same > > logic to the examples you provided, in frank version, I don't > > immediately know if one test cases does something that is a > > precondition for another test case. > > Yes, that is a real problem in the current code, but easily fixed > with comments. I think it is best when you don't need comments, but in this case, I think I have to agree with you. > > > > My version also makes it easier to run a test case entirely by itself > > which is really valuable for debugging purposes. A common thing that > > happens when you have lots of unit tests is something breaks and lots > > of tests fail. If the test cases are good, there should be just a > > couple (ideally one) test cases that directly assert the violated > > property; those are the test cases you actually want to focus on, the > > rest are noise for the purposes of that breakage. In my version, it is > > much easier to turn off the test cases that you don't care about and > > then focus in on the ones that exercise the violated property. > > > > Now I know that, hermeticity especially, but other features as well > > (test suite summary, error on unused test case function, etc) are not > > actually in KUnit as it is under consideration here. Maybe it would be > > best to save these last two patches (18/19, and 19/19) until I have > > these other features checked in and reconsider them then? > > Thanks for leaving 18/19 and 19/19 off in v4. Sure, no problem. It was pretty clear that it was a waste of both of our times to continue discussing those at this juncture. :-) Do you still want me to try to convert the DT not-exactly-unittest to KUnit? I would kind of prefer (I don't feel *super* strongly about the matter) we don't call it that since I was intending for it to be the flagship initial example, but I certainly don't mind trying to clean this patch up to get it up to snuff. It's really just a question of whether it is worth it to you. < snip > Cheers!
next prev parent reply other threads:[~2019-03-22 1:30 UTC|newest] Thread overview: 232+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-28 19:36 [RFC v3 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 01/19] kunit: test: add KUnit test runner core brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-30 3:14 ` mcgrof 2018-11-30 3:14 ` Luis Chamberlain 2018-12-01 1:51 ` brendanhiggins 2018-12-01 1:51 ` Brendan Higgins 2018-12-01 2:57 ` mcgrof 2018-12-01 2:57 ` Luis Chamberlain 2018-12-05 13:15 ` anton.ivanov 2018-12-05 13:15 ` Anton Ivanov 2018-12-05 14:45 ` arnd 2018-12-05 14:45 ` Arnd Bergmann 2018-12-05 14:49 ` anton.ivanov 2018-12-05 14:49 ` Anton Ivanov 2018-11-30 3:28 ` mcgrof 2018-11-30 3:28 ` Luis Chamberlain 2018-12-01 2:08 ` brendanhiggins 2018-12-01 2:08 ` Brendan Higgins 2018-12-01 3:10 ` mcgrof 2018-12-01 3:10 ` Luis Chamberlain 2018-12-03 22:47 ` brendanhiggins 2018-12-03 22:47 ` Brendan Higgins 2018-12-01 3:02 ` mcgrof 2018-12-01 3:02 ` Luis Chamberlain 2018-11-28 19:36 ` [RFC v3 02/19] kunit: test: add test resource management API brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 03/19] kunit: test: add string_stream a std::stream like string builder brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-30 3:29 ` mcgrof 2018-11-30 3:29 ` Luis Chamberlain 2018-12-01 2:14 ` brendanhiggins 2018-12-01 2:14 ` Brendan Higgins 2018-12-01 3:12 ` mcgrof 2018-12-01 3:12 ` Luis Chamberlain 2018-12-03 10:55 ` pmladek 2018-12-03 10:55 ` Petr Mladek 2018-12-04 0:35 ` brendanhiggins 2018-12-04 0:35 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 04/19] kunit: test: add test_stream a std::stream like logger brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 05/19] kunit: test: add the concept of expectations brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 06/19] arch: um: enable running kunit from User Mode Linux brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-28 21:26 ` robh 2018-11-28 21:26 ` Rob Herring 2018-11-30 3:37 ` mcgrof 2018-11-30 3:37 ` Luis Chamberlain 2018-11-30 14:05 ` robh 2018-11-30 14:05 ` Rob Herring 2018-11-30 18:22 ` mcgrof 2018-11-30 18:22 ` Luis Chamberlain 2018-12-03 23:22 ` brendanhiggins 2018-12-03 23:22 ` Brendan Higgins 2018-11-30 3:30 ` mcgrof 2018-11-30 3:30 ` Luis Chamberlain 2018-11-28 19:36 ` [RFC v3 07/19] kunit: test: add initial tests brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-30 3:40 ` mcgrof 2018-11-30 3:40 ` Luis Chamberlain 2018-12-03 23:26 ` brendanhiggins 2018-12-03 23:26 ` Brendan Higgins 2018-12-03 23:43 ` mcgrof 2018-12-03 23:43 ` Luis Chamberlain 2018-11-28 19:36 ` [RFC v3 08/19] arch: um: add shim to trap to allow installing a fault catcher for tests brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-30 3:34 ` mcgrof 2018-11-30 3:34 ` Luis Chamberlain 2018-12-03 23:34 ` brendanhiggins 2018-12-03 23:34 ` Brendan Higgins 2018-12-03 23:46 ` mcgrof 2018-12-03 23:46 ` Luis Chamberlain 2018-12-04 0:44 ` brendanhiggins 2018-12-04 0:44 ` Brendan Higgins 2018-11-30 3:41 ` mcgrof 2018-11-30 3:41 ` Luis Chamberlain 2018-12-03 23:37 ` brendanhiggins 2018-12-03 23:37 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 09/19] kunit: test: add the concept of assertions brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 10/19] kunit: test: add test managed resource tests brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-29 13:54 ` kieran.bingham 2018-11-29 13:54 ` Kieran Bingham 2018-12-03 23:48 ` brendanhiggins 2018-12-03 23:48 ` Brendan Higgins 2018-12-04 20:47 ` mcgrof 2018-12-04 20:47 ` Luis Chamberlain 2018-12-06 12:32 ` kieran.bingham 2018-12-06 12:32 ` Kieran Bingham 2018-12-06 15:37 ` willy 2018-12-06 15:37 ` Matthew Wilcox 2018-12-07 11:30 ` kieran.bingham 2018-12-07 11:30 ` Kieran Bingham 2018-12-11 14:09 ` pmladek 2018-12-11 14:09 ` Petr Mladek 2018-12-11 14:41 ` rostedt 2018-12-11 14:41 ` Steven Rostedt 2018-12-11 17:01 ` anton.ivanov 2018-12-11 17:01 ` Anton Ivanov 2019-02-09 0:40 ` brendanhiggins 2019-02-09 0:40 ` Brendan Higgins 2018-12-07 1:05 ` mcgrof 2018-12-07 1:05 ` Luis Chamberlain 2018-12-07 18:35 ` kent.overstreet 2018-12-07 18:35 ` Kent Overstreet 2018-11-30 3:44 ` mcgrof 2018-11-30 3:44 ` Luis Chamberlain 2018-12-03 23:50 ` brendanhiggins 2018-12-03 23:50 ` Brendan Higgins 2018-12-04 20:48 ` mcgrof 2018-12-04 20:48 ` Luis Chamberlain 2018-11-28 19:36 ` [RFC v3 12/19] kunit: add KUnit wrapper script and simple output parser brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 13/19] kunit: improve output from python wrapper brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 14/19] Documentation: kunit: add documentation for KUnit brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-29 13:56 ` kieran.bingham 2018-11-29 13:56 ` Kieran Bingham 2018-11-30 3:45 ` mcgrof 2018-11-30 3:45 ` Luis Chamberlain 2018-12-03 23:53 ` brendanhiggins 2018-12-03 23:53 ` Brendan Higgins 2018-12-06 12:16 ` kieran.bingham 2018-12-06 12:16 ` Kieran Bingham 2019-02-09 0:56 ` brendanhiggins 2019-02-09 0:56 ` Brendan Higgins 2019-02-11 12:16 ` kieran.bingham 2019-02-11 12:16 ` Kieran Bingham 2019-02-12 22:10 ` brendanhiggins 2019-02-12 22:10 ` Brendan Higgins 2019-02-13 21:55 ` kieran.bingham 2019-02-13 21:55 ` Kieran Bingham 2019-02-14 0:17 ` brendanhiggins 2019-02-14 0:17 ` Brendan Higgins 2019-02-14 17:26 ` mcgrof 2019-02-14 17:26 ` Luis Chamberlain 2019-02-14 22:07 ` brendanhiggins 2019-02-14 22:07 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 15/19] MAINTAINERS: add entry for KUnit the unit testing framework brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 16/19] arch: um: make UML unflatten device tree when testing brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-11-28 21:16 ` robh 2018-11-28 21:16 ` Rob Herring 2018-12-04 0:00 ` brendanhiggins 2018-12-04 0:00 ` Brendan Higgins 2018-11-30 3:46 ` mcgrof 2018-11-30 3:46 ` Luis Chamberlain 2018-12-04 0:02 ` brendanhiggins 2018-12-04 0:02 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 17/19] of: unittest: migrate tests to run on KUnit brendanhiggins 2018-11-28 19:36 ` Brendan Higgins [not found] ` <CAL_Jsq+09Kx7yMBC_Jw45QGmk6U_fp4N6HOZDwYrM4tWw+_dOA@mail.gmail.com> 2018-11-30 0:39 ` rdunlap 2018-11-30 0:39 ` Randy Dunlap 2018-12-04 0:13 ` brendanhiggins 2018-12-04 0:13 ` Brendan Higgins 2018-12-04 13:40 ` robh 2018-12-04 13:40 ` Rob Herring 2018-12-05 23:42 ` brendanhiggins 2018-12-05 23:42 ` Brendan Higgins 2018-12-07 0:41 ` robh 2018-12-07 0:41 ` Rob Herring 2018-12-04 0:08 ` brendanhiggins 2018-12-04 0:08 ` Brendan Higgins 2019-02-13 1:44 ` brendanhiggins 2019-02-13 1:44 ` Brendan Higgins 2019-02-14 20:10 ` robh 2019-02-14 20:10 ` Rob Herring 2019-02-14 21:52 ` brendanhiggins 2019-02-14 21:52 ` Brendan Higgins 2019-02-18 22:56 ` frowand.list 2019-02-18 22:56 ` Frank Rowand 2019-02-28 0:29 ` brendanhiggins 2019-02-28 0:29 ` Brendan Higgins 2018-12-04 10:56 ` frowand.list 2018-12-04 10:56 ` Frank Rowand 2018-11-28 19:36 ` [RFC v3 18/19] of: unittest: split out a couple of test cases from unittest brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-12-04 10:58 ` frowand.list 2018-12-04 10:58 ` Frank Rowand 2018-12-05 23:54 ` brendanhiggins 2018-12-05 23:54 ` Brendan Higgins 2019-02-14 23:57 ` frowand.list 2019-02-14 23:57 ` Frank Rowand 2019-02-15 0:56 ` brendanhiggins 2019-02-15 0:56 ` Brendan Higgins 2019-02-15 2:05 ` frowand.list 2019-02-15 2:05 ` Frank Rowand 2019-02-15 10:56 ` brendanhiggins 2019-02-15 10:56 ` Brendan Higgins 2019-02-18 22:25 ` frowand.list 2019-02-18 22:25 ` Frank Rowand 2019-02-20 20:44 ` frowand.list 2019-02-20 20:44 ` Frank Rowand 2019-02-20 20:47 ` frowand.list 2019-02-20 20:47 ` Frank Rowand 2019-02-28 3:52 ` brendanhiggins 2019-02-28 3:52 ` Brendan Higgins 2019-03-22 0:22 ` frowand.list 2019-03-22 0:22 ` Frank Rowand 2019-03-22 1:30 ` brendanhiggins [this message] 2019-03-22 1:30 ` Brendan Higgins 2019-03-22 1:47 ` frowand.list 2019-03-22 1:47 ` Frank Rowand 2019-03-25 22:15 ` brendanhiggins 2019-03-25 22:15 ` Brendan Higgins 2019-09-20 16:57 ` Rob Herring 2019-09-21 23:57 ` Frank Rowand 2019-03-22 1:34 ` frowand.list 2019-03-22 1:34 ` Frank Rowand 2019-03-25 22:18 ` brendanhiggins 2019-03-25 22:18 ` Brendan Higgins 2018-11-28 19:36 ` [RFC v3 19/19] of: unittest: split up some super large test cases brendanhiggins 2018-11-28 19:36 ` Brendan Higgins 2018-12-04 10:52 ` [RFC v3 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework frowand.list 2018-12-04 10:52 ` Frank Rowand 2018-12-04 11:40 ` frowand.list 2018-12-04 11:40 ` Frank Rowand 2018-12-04 13:49 ` robh 2018-12-04 13:49 ` Rob Herring 2018-12-05 23:10 ` brendanhiggins 2018-12-05 23:10 ` Brendan Higgins 2019-03-22 0:27 ` frowand.list 2019-03-22 0:27 ` Frank Rowand 2019-03-25 22:04 ` brendanhiggins 2019-03-25 22:04 ` 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=CAFd5g448xQLOJwVYU5Zmu4+OPWuboiWZPhBvK6au8Pgm5B9haQ@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).