lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 23 Aug 2019 10:54:45 -0700
From:   Brendan Higgins <brendanhiggins@...gle.com>
To:     shuah <shuah@...nel.org>
Cc:     Frank Rowand <frowand.list@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Kees Cook <keescook@...gle.com>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Rob Herring <robh@...nel.org>, Stephen Boyd <sboyd@...nel.org>,
        "Theodore Ts'o" <tytso@....edu>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        devicetree <devicetree@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        kunit-dev@...glegroups.com,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org,
        linux-kbuild <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        linux-um@...ts.infradead.org,
        Sasha Levin <Alexander.Levin@...rosoft.com>,
        "Bird, Timothy" <Tim.Bird@...y.com>,
        Amir Goldstein <amir73il@...il.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Daniel Vetter <daniel@...ll.ch>, Jeff Dike <jdike@...toit.com>,
        Joel Stanley <joel@....id.au>,
        Julia Lawall <julia.lawall@...6.fr>,
        Kevin Hilman <khilman@...libre.com>,
        Knut Omang <knut.omang@...cle.com>,
        Logan Gunthorpe <logang@...tatee.com>,
        Petr Mladek <pmladek@...e.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Richard Weinberger <richard@....at>,
        David Rientjes <rientjes@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>, wfg@...ux.intel.com
Subject: Re: [PATCH v14 01/18] kunit: test: add KUnit test runner core

On Fri, Aug 23, 2019 at 10:34 AM shuah <shuah@...nel.org> wrote:
>
> On 8/23/19 11:27 AM, Brendan Higgins wrote:
> > On Fri, Aug 23, 2019 at 10:05 AM shuah <shuah@...nel.org> wrote:
> >>
> >> On 8/23/19 10:48 AM, Brendan Higgins wrote:
> >>> On Fri, Aug 23, 2019 at 8:33 AM shuah <shuah@...nel.org> wrote:
> >>>>
> >>>> Hi Brendan,
> >>>>
> >>>> On 8/20/19 5:20 PM, Brendan Higgins wrote:
> >>>>> Add core facilities for defining unit tests; this provides a common way
> >>>>> to define test cases, functions that execute code which is under test
> >>>>> and determine whether the code under test behaves as expected; this also
> >>>>> provides a way to group together related test cases in test suites (here
> >>>>> we call them test_modules).
> >>>>>
> >>>>> Just define test cases and how to execute them for now; setting
> >>>>> expectations on code will be defined later.
> >>>>>
> >>>>> Signed-off-by: Brendan Higgins <brendanhiggins@...gle.com>
> >>>>> Reviewed-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> >>>>> Reviewed-by: Logan Gunthorpe <logang@...tatee.com>
> >>>>> Reviewed-by: Luis Chamberlain <mcgrof@...nel.org>
> >>>>> Reviewed-by: Stephen Boyd <sboyd@...nel.org>
> >>>>> ---
> >>>>>     include/kunit/test.h | 179 ++++++++++++++++++++++++++++++++++++++++
> >>>>>     kunit/Kconfig        |  17 ++++
> >>>>>     kunit/Makefile       |   1 +
> >>>>>     kunit/test.c         | 191 +++++++++++++++++++++++++++++++++++++++++++
> >>>>>     4 files changed, 388 insertions(+)
> >>>>>     create mode 100644 include/kunit/test.h
> >>>>>     create mode 100644 kunit/Kconfig
> >>>>>     create mode 100644 kunit/Makefile
> >>>>>     create mode 100644 kunit/test.c
> >>>>>
> >>>>> diff --git a/include/kunit/test.h b/include/kunit/test.h
> >>>>> new file mode 100644
> >>>>> index 0000000000000..e0b34acb9ee4e
> >>>>> --- /dev/null
> >>>>> +++ b/include/kunit/test.h
> >>>>> @@ -0,0 +1,179 @@
> >>>>> +/* SPDX-License-Identifier: GPL-2.0 */
> >>>>> +/*
> >>>>> + * Base unit test (KUnit) API.
> >>>>> + *
> >>>>> + * Copyright (C) 2019, Google LLC.
> >>>>> + * Author: Brendan Higgins <brendanhiggins@...gle.com>
> >>>>> + */
> >>>>> +
> >>>>> +#ifndef _KUNIT_TEST_H
> >>>>> +#define _KUNIT_TEST_H
> >>>>> +
> >>>>> +#include <linux/types.h>
> >>>>> +
> >>>>> +struct kunit;
> >>>>> +
> >>>>> +/**
> >>>>> + * struct kunit_case - represents an individual test case.
> >>>>> + * @run_case: the function representing the actual test case.
> >>>>> + * @name: the name of the test case.
> >>>>> + *
> >>>>> + * A test case is a function with the signature, ``void (*)(struct kunit *)``
> >>>>> + * that makes expectations (see KUNIT_EXPECT_TRUE()) about code under test. Each
> >>>>> + * test case is associated with a &struct kunit_suite and will be run after the
> >>>>> + * suite's init function and followed by the suite's exit function.
> >>>>> + *
> >>>>> + * A test case should be static and should only be created with the KUNIT_CASE()
> >>>>> + * macro; additionally, every array of test cases should be terminated with an
> >>>>> + * empty test case.
> >>>>> + *
> >>>>> + * Example:
> >>>>
> >>>> Can you fix these line continuations. It makes it very hard to read.
> >>>> Sorry for this late comment. These comments lines are longer than 80
> >>>> and wrap.
> >>>
> >>> None of the lines in this commit are over 80 characters in column
> >>> width. Some are exactly 80 characters (like above).
> >>>
> >>> My guess is that you are seeing the diff added text (+ ), which when
> >>> you add that to a line which is exactly 80 char in length ends up
> >>> being over 80 char in email. If you apply the patch you will see that
> >>> they are only 80 chars.
> >>>
> >>>>
> >>>> There are several comment lines in the file that are way too long.
> >>>
> >>> Note that checkpatch also does not complain about any over 80 char
> >>> lines in this file.
> >>>
> >>> Sorry if I am misunderstanding what you are trying to tell me. Please
> >>> confirm either way.
> >>>
> >>
> >> WARNING: Avoid unnecessary line continuations
> >> #258: FILE: include/kunit/test.h:137:
> >> +                */                                                            \
> >>
> >> total: 0 errors, 2 warnings, 388 lines checked
> >
> > Ah, okay so you don't like the warning about the line continuation.
> > That's not because it is over 80 char, but because there is a line
> > continuation after a comment. I don't really see a way to get rid of
> > it without removing the comment from inside the macro.
> >
> > I put this TODO there in the first place a Luis' request, and I put it
> > in the body of the macro because this macro already had a kernel-doc
> > comment and I didn't think that an implementation detail TODO belonged
> > in the user documentation.
> >
> >> Go ahead fix these. It appears there are few lines that either longer
> >> than 80. In general, I keep them around 75, so it is easier read.
> >
> > Sorry, the above is the only checkpatch warning other than the
> > reminder to update the MAINTAINERS file.
> >
> > Are you saying you want me to go through and make all the lines fit in
> > 75 char column width? I hope not because that is going to be a pretty
> > substantial change to make.
> >
>
> There are two things with these comment lines. One is checkpatch
> complaining and the other is general readability.

So for the checkpatch warning, do you want me to move the comment out
of the macro body into the kernel-doc comment? I don't really think it
is the right place for a comment of this nature, but I think it is
probably better than dropping it entirely (I don't see how else to do
it without just removing the comment entirely).

As for general readability, are you asking me to readjust all my code
in all 18 patches to fit in 75 chars? Sorry for the confusion, I am
just really surprised by this request. I thought the policy is 80
char, and reflowing all of my code in this patchset to 75 chars is not
a quick and easy thing to do. Additionally, there are some other short
term and long term issues about enforcing a 75 char limit on the KUnit
code.

Sorry, maybe I am just not understanding what you are asking me.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ