Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2913857pxj; Mon, 14 Jun 2021 09:58:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwL7mwjxGboeFnGisH+1qKbF6zV4KuIFlQBm18X3+odkglsn+ds5QKHB16zC0f4gvO7GW9L X-Received: by 2002:a05:6402:27c9:: with SMTP id c9mr18491992ede.371.1623689909002; Mon, 14 Jun 2021 09:58:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623689908; cv=none; d=google.com; s=arc-20160816; b=CTLzR2irgz0RnVgJuovgIxY5+8H5Ae4MMNSvW+Oym1IW3jxl/p34JXlcVbGDVTXs1B sCk2zO5uKaxIUntbusaqViloiGagIfGWzWyULg7yv6IB1jAe2ChMTt3kGgJgi5R5949u Z3TvGfQje4nd5QmhCNsSmQ6keH6Rl+3pUIZsrZj/ciJK3Xua6lfaDBEt5zaIeN5uqK+I 8W4uz66F/e2llgISuEXAT/YZkPZdB0UF6qVP/MnW2jUg3062af4fsGaUfa0PwWRdLFLm /gzKslowTNnIa1YNJSdvZz8xiPa0qp6cAV0OMDODXr2jJMDlDbh+aKMAYRHY0htbFt22 Syog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=NUwZeZE9lThBqFXb/d9fj89iQq04OGqPFkP7zLQbmok=; b=WhRf3fASYY/Uydj/r9PRZMjH1uKK+je30nRNgOQ3TskEpkU61JDTLHcg+5Lya6CIbj nS0GPCUhbUcvlDYP6HMH/4LUvhgC1Z3573j4BQBZFotsnO3cc6q8xDXvfZtByFh8A/Gt BrwbMkCguQ8VI4i3bGHn3tdJ+fz3/Mw00k4SCqg1y+1KdVGvQ7xmcmp/83XD0ibFCOIc mwX6oX2FQ4Z+eOK0OXfRovQm4LyzmDqAdWxdUs/geHJHr/b+DgFT4ebhSyGUhOeB6ASs shfbXmVsFRkmXA4D3xikcbDeKxxlhXDmLeuSlPksGWGwfl7IHr55PB8+W3Gx1BaWEpBE MJ4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=J0gH0Ukm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m9si12077550eds.467.2021.06.14.09.58.06; Mon, 14 Jun 2021 09:58:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=J0gH0Ukm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235185AbhFNQ6F (ORCPT + 99 others); Mon, 14 Jun 2021 12:58:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234789AbhFNQ6E (ORCPT ); Mon, 14 Jun 2021 12:58:04 -0400 Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A330C061574 for ; Mon, 14 Jun 2021 09:56:01 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id a6so40403788ioe.0 for ; Mon, 14 Jun 2021 09:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NUwZeZE9lThBqFXb/d9fj89iQq04OGqPFkP7zLQbmok=; b=J0gH0UkmMve3krqAjAkspun6nf5wq4F//O0dtEdW9N/88dko1cyFjwOmyXfa+U20li pn/kvINOR047jANzZsVLWiej/mU8Vyryu8jKb8STEMlLUwcpdOROnN0glUFZv7akj9M8 BThICd1j/Ib1jEZZvHHj+0o+n+q/ehe1ReF4RPlude2tRcaRvoiPBh4vg4UyfgM7qfi5 eWzVzhWdv0HcJR4I08WamCoQlJyYTaZ3zarHCvqvrzaqf3jqzqHuuNwkfkOnUbiQqLLX xQ8Vh6gw8HfKtl4e8G/sPjGnClYrgoQUntYZoyPx1nzBLvk28kJ3lLKEngl4NCGbCVnY L49Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NUwZeZE9lThBqFXb/d9fj89iQq04OGqPFkP7zLQbmok=; b=BRbctWBitS7sZ9S9WaennJ1ob2EG/zNCgaHHJghstXHnhlDhgbqL8+9tD0K1e6E1k+ gsWC7DbGdZrv8yqONDc69FBZzGLqLea3C0ZneiUUSCLDp6oXALMYzKRZQz0HRqYpt8sq PwD7wyolsGFiskzRg/vwvEfst3mWb8pggREwu4G+WvubeDadpCzxw05uopemqdd5jSdb 8/y98YfOvK5dU8fajVZsrQvlXmkZrGy1tRPF+O+fPg9PWLgUM6oKxDsL9muNFTLiFNUA vkKoAeTKfyN2W1+KEyXfFdOVRFFINukyfRWZzEdXPIX0DB5gtPHJLq71+6EUyTv0rqwW +9jw== X-Gm-Message-State: AOAM532gGdAxVGJzMv0xTyzqqATeL+qzBNRtmJ48yCFId79Yy3ZdKBcD dI4CPZo5Q3yIi9VwLS+s0zVz3KDWWuryZNCbOgtPIS5pJXCEGw== X-Received: by 2002:a05:6602:1810:: with SMTP id t16mr14797059ioh.48.1623689760679; Mon, 14 Jun 2021 09:56:00 -0700 (PDT) MIME-Version: 1.0 References: <20210610163959.71634-1-andrealmeid@collabora.com> <20210610163959.71634-2-andrealmeid@collabora.com> <20210614064205.GA29220@lst.de> In-Reply-To: <20210614064205.GA29220@lst.de> From: Daniel Latypov Date: Mon, 14 Jun 2021 09:55:48 -0700 Message-ID: Subject: Re: [PATCH v3 1/1] lib: Convert UUID runtime test to KUnit To: Christoph Hellwig Cc: =?UTF-8?Q?Andr=C3=A9_Almeida?= , Andy Shevchenko , Linux Kernel Mailing List , Brendan Higgins , "open list:KERNEL SELFTEST FRAMEWORK" , KUnit Development , Shuah Khan , ~lkcamp/patches@lists.sr.ht, nfraprado@collabora.com, leandro.ribeiro@collabora.com, Vitor Massaru Iha , lucmaga@gmail.com, David Gow , tales.aparecida@gmail.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jun 13, 2021 at 11:42 PM Christoph Hellwig wrote: > > > +config UUID_KUNIT_TEST > > + tristate "Unit test for UUID" if !KUNIT_ALL_TESTS > > + depends on KUNIT > > + default KUNIT_ALL_TESTS > > + help > > + This builds the UUID unit test. > > Does this first help line really add any value if we have this second > line: > > > + Tests parsing functions for UUID/GUID strings. > > ? > > > + If unsure, say N. > > Not specific to this case, but IMHO we can drop this line for all kunit > tests as it is completely obvious. > > > @@ -354,5 +353,6 @@ obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o > > obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o > > obj-$(CONFIG_BITS_TEST) += test_bits.o > > obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o > > +obj-$(CONFIG_UUID_KUNIT_TEST) += test_uuid.o > > Another meta-comment on the kunit tests: Wouldn't it make more sense > to name them all as CONFIG_KUNIT_TEST_FOO to allow for easier grepping? But putting them in a "kunit namespace" by prefixing them as such would be misleading, IMO. The tests live adjacent to the code they test and are owned by the same maintainers, or at least that's the intent. And if the goal is just to find configs, then I don't see much difference between "config.*KUNIT_TEST" and "config KUNIT_TEST.*" > > > -struct test_uuid_data { > > +struct test_data { > > const char *uuid; > > guid_t le; > > uuid_t be; > > }; > > > > -static const struct test_uuid_data test_uuid_test_data[] = { > > +static const struct test_data correct_data[] = { > > What is the reason for these renames? Is this a pattern used for > other kunit tests? No, this is not a pattern. The structs can be renamed back. > > > +static void uuid_correct_le(struct kunit *test) > > { > > + guid_t le; > > + const struct test_data *data = (const struct test_data *)(test->param_value); > > Overly long line. But as far as I can tell there is no need for the > case that causes this mess anyway given that param_value is a > "const void *". There is no need for the cast or the brace, yes. This is my fault. The documentation has both since I had thought that would make how it works more clear: https://www.kernel.org/doc/html/latest/dev-tools/kunit/usage.html#parameterized-testing I don't really understand my past thought process... > > Same for all the other instances of this. > > > +static void uuid_wrong_le(struct kunit *test) > > { > > guid_t le; > > + const char **data = (const char **)(test->param_value); > > No need for the second pair of braces. Same for various other instances.