From: Michael Ellerman <mpe@ellerman.id.au>
To: Nathan Lynch <nathanl@linux.ibm.com>
Cc: Tyrel Datwyler <tyreld@linux.ibm.com>,
mwb@linux.vnet.ibm.com, msuchanek@suse.de,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/pseries: fix of_read_drc_info_cell() to point at next record
Date: Fri, 13 Mar 2020 13:29:13 +1100 [thread overview]
Message-ID: <87h7ytxa12.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <87r1xx36u5.fsf@linux.ibm.com>
Nathan Lynch <nathanl@linux.ibm.com> writes:
> Michael Ellerman <mpe@ellerman.id.au> writes:
>>
>> It would also be *really* nice if we had some unit tests for this
>> parsing code, it's demonstrably very bug prone.
>
> Can you say more about what form unit tests could take? Like some self
> tests that run at boot time, or is there a way to run the code in a user
> space test harness?
It depends.
A userspace selftest is ideal as it's the easiest option for people to
run, ie. they just have to build a user program. There's also CI systems
setup to run the kernel selftests automatically.
See eg. tools/testing/selftests/powerpc/vphn/vphn.c
We also have boot time tests, they are good for code that we want to
test in the kernel proper, or that are hard to extract into a userspace
program. Most of those are configurable, so testing them requires
someone to enable the appropriate CONFIG_FOO and build & boot that
kernel. That reduces coverage obviously.
See eg. arch/powerpc/lib/code-patching.c
These days there's also kunit, which is a "proper" way to do kernel unit
tests. They get built into the kernel but then there's some support for
running those like a user program using UML on x86. On powerpc we'd have
to boot the kunit enabled kernel on hardware or in qemu to exercise the
tests. So they're essentially just boot time tests but with some nicer
infrastructure vs doing it all by hand like we used to.
In this case the actual function we want to test could be trivially
built into a userspace program, but the underlying device tree helpers
probably can't be.
eg. drivers/of/property.c is quite large and contains quite a few
things, we'd need to shim quite a bit to get that building in userspace
I suspect, which then becomes a maintenance burden.
So this is probably a good candidate for a kunit test, though I haven't
personally written/converted any tests to kunit so I can't say exactly
how easy that is.
cheers
next prev parent reply other threads:[~2020-03-13 2:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-07 2:45 [PATCH] powerpc/pseries: fix of_read_drc_info_cell() to point at next record Tyrel Datwyler
2020-03-10 17:25 ` Nathan Lynch
2020-03-10 18:18 ` Tyrel Datwyler
2020-03-12 5:43 ` Michael Ellerman
2020-03-12 15:56 ` Nathan Lynch
2020-03-13 2:29 ` Michael Ellerman [this message]
2020-03-12 21:34 ` Tyrel Datwyler
2020-03-13 2:16 ` Michael Ellerman
2020-03-26 12:06 ` Michael Ellerman
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=87h7ytxa12.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=msuchanek@suse.de \
--cc=mwb@linux.vnet.ibm.com \
--cc=nathanl@linux.ibm.com \
--cc=tyreld@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).