From: John Johansen <john.johansen@canonical.com>
To: Rae Moar <rmoar@google.com>,
brendanhiggins@google.com, davidgow@google.com,
dlatypov@google.com
Cc: skhan@linuxfoundation.org, tales.aparecida@gmail.com,
kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, apparmor@lists.ubuntu.com
Subject: Re: [PATCH v3 0/2] kunit: add macro to allow conditionally exposing static symbols to tests
Date: Tue, 6 Dec 2022 18:43:05 -0800 [thread overview]
Message-ID: <3bc67108-9f4a-4cd7-619d-d61816625e1a@canonical.com> (raw)
In-Reply-To: <20221207014024.340230-1-rmoar@google.com>
On 12/6/22 17:40, Rae Moar wrote:
> Currently in order to test a static function, tests must be included in the
> same translation unit as the function. However, this can cause issues with
> including implementation and test code in the same file. As an alternative,
> the first patch in this series creates a macro that will set a function to
> be static or not depending on whether CONFIG_KUNIT is enabled. This allows
> the function to be visible during testing and static otherwise.
>
> As an example, the current status quo to test static functions is:
>
> === test.c ===
>
> static void test_case(struct kunit *test)
> {
> KUNIT_EXPECT_EQ(test, my_func_to_test(), 2);
> }
>
> Then the tests are included in the implementation file as a workaround to
> the issue of testing static functions:
>
> === implementation.c ===
>
> static int my_func_to_test() {...}
> ...
> #include "test.c"
>
> Instead, the function could be defined with this new macro:
>
> === implementation.c ===
>
> VISIBLE_IF_KUNIT int my_func_to_test() {...}
>
> The first patch also creates a macro that will export a symbol into a kunit
> testing namespace only if CONFIG_KUNIT is enabled. This follows the logic
> above and allows symbols to be conditionally exported based on the testing
> status.
>
> The second patch in the series updates the policy_unpack test in AppArmor
> to show an example of how to use both of these macros in order to address
> the issue of testing static functions. Additionally, the patch allows the
> policy_unpack test to be built as a module.
>
> Changes since v2:
> - Add mention of namespacing symbols to the commit message of the
> second patch.
> - Change module name in the second patch from policy_unpack_test to
> apparmor_policy_unpack_test.
>
> Changes since v1:
> - Changed the namespace of exported symbols for the apparmor
> policy_unpack_test by adding the aa_ prefix.
> - Separated the documentation comments for macros in
> include/kunit/visibility.h.
> - Changed copyright date and author for include/kunit/visibility.h.
>
> Rae Moar (2):
> kunit: add macro to allow conditionally exposing static symbols to
> tests
> apparmor: test: make static symbols visible during kunit testing
>
> include/kunit/visibility.h | 33 +++
> security/apparmor/Kconfig | 4 +-
> security/apparmor/Makefile | 3 +
> security/apparmor/include/policy_unpack.h | 50 +++++
> security/apparmor/policy_unpack.c | 238 ++++++++++------------
> security/apparmor/policy_unpack_test.c | 69 ++++---
> 6 files changed, 229 insertions(+), 168 deletions(-)
> create mode 100644 include/kunit/visibility.h
>
>
> base-commit: 0f08f3e2a0186dfb8e33cb46105228eb18448a0e
thanks Rae,
looks good to me, David unless you tell me otherwise I assume this is
still going in via the kselftest/kunit tree.
next prev parent reply other threads:[~2022-12-07 2:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-07 1:40 Rae Moar
2022-12-07 1:40 ` [PATCH v3 1/2] " Rae Moar
2022-12-07 1:40 ` [PATCH v3 2/2] apparmor: test: make static symbols visible during kunit testing Rae Moar
2022-12-07 2:43 ` John Johansen [this message]
2022-12-07 2:54 ` [PATCH v3 0/2] kunit: add macro to allow conditionally exposing static symbols to tests David Gow
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=3bc67108-9f4a-4cd7-619d-d61816625e1a@canonical.com \
--to=john.johansen@canonical.com \
--cc=apparmor@lists.ubuntu.com \
--cc=brendanhiggins@google.com \
--cc=davidgow@google.com \
--cc=dlatypov@google.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=rmoar@google.com \
--cc=skhan@linuxfoundation.org \
--cc=tales.aparecida@gmail.com \
/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
all inboxes | Powered by JetHome®