On Mon, Aug 12, 2019 at 04:57:00PM -0700, Stephen Boyd wrote: > Quoting Brendan Higgins (2019-08-12 11:24:08) > > Add support for expectations, which allow properties to be specified and > > then verified in tests. > > > > Signed-off-by: Brendan Higgins <brendanhigg...@google.com> > > Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> > > Reviewed-by: Logan Gunthorpe <log...@deltatee.com> > > Reviewed-by: Stephen Boyd <sb...@kernel.org> > > Just some minor nits again. > > > diff --git a/include/kunit/test.h b/include/kunit/test.h > > index d0bf112910caf..2625bcfeb19ac 100644 > > --- a/include/kunit/test.h > > +++ b/include/kunit/test.h > > @@ -9,8 +9,10 @@ > > #ifndef _KUNIT_TEST_H > > #define _KUNIT_TEST_H > > > > +#include <linux/kernel.h> > > #include <linux/types.h> > > #include <linux/slab.h> > > +#include <kunit/assert.h> > > Can you alphabet sort these?
Sure. Will fix. > > > > struct kunit_resource; > > > > @@ -319,4 +321,845 @@ void __printf(3, 4) kunit_printk(const char *level, > > #define kunit_err(test, fmt, ...) \ > > kunit_printk(KERN_ERR, test, fmt, ##__VA_ARGS__) > > > > +/* > > + * Generates a compile-time warning in case of comparing incompatible > > types. > > + */ > > +#define __kunit_typecheck(lhs, rhs) \ > > + ((void) __typecheck(lhs, rhs)) > > Is there a reason why this can't be inlined and the __kunit_typecheck() > macro can't be removed? No real reason anymore. I used it in multiple places before and we weren't sure if we wanted to stick with the warnings that __typecheck produces long term, but now that it is only used in one place, I guess that doesn't make sense anymore. Will fix. > > + > > +/** > > + * KUNIT_SUCCEED() - A no-op expectation. Only exists for code clarity. > > + * @test: The test context object. > [...] > > + * @condition: an arbitrary boolean expression. The test fails when this > > does > > + * not evaluate to true. > > + * > > + * This and expectations of the form `KUNIT_EXPECT_*` will cause the test > > case > > + * to fail when the specified condition is not met; however, it will not > > prevent > > + * the test case from continuing to run; this is otherwise known as an > > + * *expectation failure*. > > + */ > > +#define KUNIT_EXPECT_TRUE(test, condition) \ > > + KUNIT_TRUE_ASSERTION(test, KUNIT_EXPECTATION, condition) > > A lot of these macros seem double indented. In a case you pointed out in the preceding patch, I was just keeping the arguments column aligned. In this case I am just indenting two tabs for a line continuation. I thought I found other instances in the kernel that did this early on (and that's also what the Linux kernel vim plugin wanted me to do). After a couple of spot checks, it seems like one tab for this kind of line continuation seems more common. I personally don't feel strongly about any particular version. I just want to know now what the correct indentation is for macros before I go through and change them all. I think there are three cases: #define macro0(param0, param1) \ a_really_long_macro(...) In this first case, I use two tabs for the first indent, I think you are telling me this should be one tab. #define macro1(param0, param1) { \ statement_in_a_block0; \ statement_in_a_block1; \ ... \ } In this case, every line is in a block and is indented as it would be in a function body. I think you are okay with this, and now that I am thinking about it, what I think you are proposing for macro0 will make these two cases more consistent. #define macro2(param0, \ param1, \ param2, \ param3, \ ..., \ paramn) ... \ In this last case, the body would be indented as in macro0, or macro1, but the parameters passed into the macro are column aligned, consistent with one of the acceptable ways of formatting function parameters that don't fit on a single line. In all cases, I put 1 space in between the closing parameter paren and the line continuation `\`, if only one `\` is needed. Otherwise, I align all the `\s` to the 80th column. Is this okay, or would you prefer that I align them all to the 80th column, or something else? > > + > > +#define KUNIT_EXPECT_TRUE_MSG(test, condition, fmt, ...) > > \ > > + KUNIT_TRUE_MSG_ASSERTION(test, > > \ > > + KUNIT_EXPECTATION, > > \ > > + condition, > > \ > > + fmt, > > \ > > + ##__VA_ARGS__) > > + _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm