libnvdimm: Enable unit test infrastructure compile checks
diff mbox series

Message ID 156080474760.3765313.13075804303259765566.stgit@dwillia2-desk3.amr.corp.intel.com
State Superseded
Headers show
Series
  • libnvdimm: Enable unit test infrastructure compile checks
Related show

Commit Message

Dan Williams June 17, 2019, 8:52 p.m. UTC
The infrastructure to mock core libnvdimm routines for unit testing
purposes is prone to bitrot relative to refactoring of that core.
Arrange for the unit test core to be built when CONFIG_COMPILE_TEST=y.
This does not result in a functional unit test environment, it is only a
helper for 0day to catch unit test build regressions.

Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 drivers/nvdimm/Kconfig  |   11 +++++++++++
 drivers/nvdimm/Makefile |    4 ++++
 2 files changed, 15 insertions(+)

Comments

Christoph Hellwig June 19, 2019, 11:23 a.m. UTC | #1
On Mon, Jun 17, 2019 at 01:52:27PM -0700, Dan Williams wrote:
> The infrastructure to mock core libnvdimm routines for unit testing
> purposes is prone to bitrot relative to refactoring of that core.
> Arrange for the unit test core to be built when CONFIG_COMPILE_TEST=y.
> This does not result in a functional unit test environment, it is only a
> helper for 0day to catch unit test build regressions.

Looks fine:

Reviewed-by: Christoph Hellwig <hch@lst.de>

I'm still curious what the point of hiding kernel code in tools/
is vs fully integrating it with the build system.
Dan Williams June 19, 2019, 4:27 p.m. UTC | #2
On Wed, Jun 19, 2019 at 4:23 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Jun 17, 2019 at 01:52:27PM -0700, Dan Williams wrote:
> > The infrastructure to mock core libnvdimm routines for unit testing
> > purposes is prone to bitrot relative to refactoring of that core.
> > Arrange for the unit test core to be built when CONFIG_COMPILE_TEST=y.
> > This does not result in a functional unit test environment, it is only a
> > helper for 0day to catch unit test build regressions.
>
> Looks fine:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> I'm still curious what the point of hiding kernel code in tools/
> is vs fully integrating it with the build system.

The separation of tools/ is due to way the "--wrap=" ldflag behaves.
It can only wrap symbols across a module linking boundary. So to
produce a setup where libnvdimm is ingesting faked responses it all
needs to be built as external modules and relinked.

It's an inelegant way to get some test coverage beyond what qemu-kvm
can do, my hope is that down the road I can use the new Kunit
infrastructure to do something similar in a cleaner / more formal way.

Patch
diff mbox series

diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig
index 54500798f23a..57d3a6c3ac70 100644
--- a/drivers/nvdimm/Kconfig
+++ b/drivers/nvdimm/Kconfig
@@ -118,4 +118,15 @@  config NVDIMM_KEYS
 	depends on ENCRYPTED_KEYS
 	depends on (LIBNVDIMM=ENCRYPTED_KEYS) || LIBNVDIMM=m
 
+config NVDIMM_TEST_BUILD
+	bool "Build the unit test core"
+	depends on COMPILE_TEST
+	default COMPILE_TEST
+	help
+	  Build the core of the unit test infrastructure.  The result of
+	  this build is non-functional for unit test execution, but it
+	  otherwise helps catch build errors induced by changes to the
+	  core devm_memremap_pages() implementation and other
+	  infrastructure.
+
 endif
diff --git a/drivers/nvdimm/Makefile b/drivers/nvdimm/Makefile
index 6f2a088afad6..40080c120363 100644
--- a/drivers/nvdimm/Makefile
+++ b/drivers/nvdimm/Makefile
@@ -28,3 +28,7 @@  libnvdimm-$(CONFIG_BTT) += btt_devs.o
 libnvdimm-$(CONFIG_NVDIMM_PFN) += pfn_devs.o
 libnvdimm-$(CONFIG_NVDIMM_DAX) += dax_devs.o
 libnvdimm-$(CONFIG_NVDIMM_KEYS) += security.o
+
+TOOLS := ../../tools
+TEST_SRC := $(TOOLS)/testing/nvdimm/test
+obj-$(CONFIG_NVDIMM_TEST_BUILD) := $(TEST_SRC)/iomap.o