linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Isabella Basso <isabellabdoamaral@usp.br>
Cc: linux@sciencehorizons.net, geert@linux-m68k.org,
	ferreiraenzoa@gmail.com, augusto.duraes33@gmail.com,
	brendanhiggins@google.com, dlatypov@google.com,
	davidgow@google.com, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org, kunit-dev@googlegroups.com,
	~lkcamp/patches@lists.sr.ht, rodrigosiqueiramelo@gmail.com
Subject: Re: [PATCH 2/6] test_hash.c: move common definitions to top of file
Date: Thu, 26 Aug 2021 16:36:34 +0200	[thread overview]
Message-ID: <CANpmjNPdP4OZGE3is4twths1fejCjZeEKAweVpgdqBUc=e59ww@mail.gmail.com> (raw)
In-Reply-To: <20210826012626.1163705-3-isabellabdoamaral@usp.br>

On Thu, 26 Aug 2021 at 03:26, 'Isabella Basso' via KUnit Development
<kunit-dev@googlegroups.com> wrote:
> Keep function signatures minimal by making common definitions static.
> This does not change any behavior.

This seems like an odd change; if I read it right it's changing the
out-param passed to test_int_hash() to simply be static globals.

For one, it makes the code harder to read because now test_int_hash()
is no longer "pure" (no global side-effects ... modulo printfs), and
what was previously an out-param, is now a global.

Unfortunately this is poor style and likely to lead to hard-to-debug
problems. One such problem is if suddenly you have multiple threads
involved. While this is just a test and unlikely to be a problem, I
would recommend not introducing global state carelessly.

An alternative common idiom, where a set of variables are always
passed around to other functions, is to introduce a struct and pass a
pointer to it along.

> Signed-off-by: Isabella Basso <isabellabdoamaral@usp.br>
> ---
>  lib/test_hash.c | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/lib/test_hash.c b/lib/test_hash.c
> index d4b0cfdb0377..8bcc645a7294 100644
> --- a/lib/test_hash.c
> +++ b/lib/test_hash.c
> @@ -23,6 +23,11 @@
>  #include <linux/stringhash.h>
>  #include <linux/printk.h>
>
> +#define SIZE 256 /* Run time is cubic in SIZE */
> +
> +static u32 string_or; /* stores or-ed string output */
> +static u32 hash_or[2][33] = { { 0, } }; /* stores or-ed hash output */

These now use up memory for as long as this module is loaded, vs.
before where it would only use up stack space. (For a test that's not
a problem, but in non-test code it might.)

>  /* 32-bit XORSHIFT generator.  Seed must not be zero. */
>  static u32 __init __attribute_const__
>  xorshift(u32 seed)
> @@ -66,7 +71,7 @@ fill_buf(char *buf, size_t len, u32 seed)
>   * recompile and re-test the module without rebooting.
>   */
>  static bool __init
> -test_int_hash(unsigned long long h64, u32 hash_or[2][33])
> +test_int_hash(unsigned long long h64)
>  {
>         int k;
>         u32 h0 = (u32)h64, h1, h2;
> @@ -123,17 +128,15 @@ test_int_hash(unsigned long long h64, u32 hash_or[2][33])
>         return true;
>  }
>
> -#define SIZE 256       /* Run time is cubic in SIZE */
> -
>  static int __init
>  test_hash_init(void)
>  {
>         char buf[SIZE+1];
> -       u32 string_or = 0, hash_or[2][33] = { { 0, } };
>         unsigned tests = 0;
>         unsigned long long h64 = 0;
>         int i, j;
>
> +       string_or = 0;

That's another problem with changes like this; now the compiler has no
chance to warn you in case the variable is not initialized correctly.

Also, I don't see string_or used anywhere else. Why make it global?
If a later change would require that, it should say so in the commit
message. But my guess is you can avoid all that by bundling everything
up in a struct.

>         fill_buf(buf, SIZE, 1);
>
>         /* Test every possible non-empty substring in the buffer. */
> @@ -161,7 +164,7 @@ test_hash_init(void)
>
>                         string_or |= h0;
>                         h64 = h64 << 32 | h0;   /* For use with hash_64 */
> -                       if (!test_int_hash(h64, hash_or))
> +                       if (!test_int_hash(h64))
>                                 return -EINVAL;
>                         tests++;
>                 } /* i */
> --
> 2.33.0
>
> --
> You received this message because you are subscribed to the Google Groups "KUnit Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kunit-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kunit-dev/20210826012626.1163705-3-isabellabdoamaral%40usp.br.

  reply	other threads:[~2021-08-26 14:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26  1:26 [PATCH 0/6] test_hash.c: refactor into KUnit Isabella Basso
2021-08-26  1:26 ` [PATCH 1/6] hash.h: remove unused define directive Isabella Basso
2021-08-26  4:01   ` David Gow
2021-09-05 22:31     ` Isabella B do Amaral
2021-08-26  1:26 ` [PATCH 2/6] test_hash.c: move common definitions to top of file Isabella Basso
2021-08-26 14:36   ` Marco Elver [this message]
2021-09-05 22:40     ` Isabella B do Amaral
2021-08-26  1:26 ` [PATCH 3/6] test_hash.c: split test_int_hash into arch-specific functions Isabella Basso
2021-08-26  4:21   ` David Gow
2021-09-05 22:53     ` Isabella B do Amaral
2021-08-26  1:26 ` [PATCH 4/6] test_hash.c: split test_hash_init Isabella Basso
2021-08-26  1:26 ` [PATCH 5/6] lib/Kconfig.debug: properly split hash test kernel entries Isabella Basso
2021-08-26  1:26 ` [PATCH 6/6] test_hash.c: refactor into kunit Isabella Basso
2021-08-26  4:26   ` David Gow
2021-09-05 23:32     ` Isabella B do Amaral
2021-08-26  6:00   ` kernel test robot
2021-08-26 10:10   ` kernel test robot
2021-08-26  1:36 ` [PATCH 0/6] test_hash.c: refactor into KUnit Daniel Latypov

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='CANpmjNPdP4OZGE3is4twths1fejCjZeEKAweVpgdqBUc=e59ww@mail.gmail.com' \
    --to=elver@google.com \
    --cc=augusto.duraes33@gmail.com \
    --cc=brendanhiggins@google.com \
    --cc=davidgow@google.com \
    --cc=dlatypov@google.com \
    --cc=ferreiraenzoa@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=isabellabdoamaral@usp.br \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux@sciencehorizons.net \
    --cc=rodrigosiqueiramelo@gmail.com \
    --cc=~lkcamp/patches@lists.sr.ht \
    /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).