All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] libnvdimm: Enable unit test infrastructure compile checks
@ 2019-06-17 20:52 Dan Williams
  2019-06-19 11:23   ` Christoph Hellwig
  0 siblings, 1 reply; 5+ messages in thread
From: Dan Williams @ 2019-06-17 20:52 UTC (permalink / raw)
  To: linux-nvdimm
  Cc: Jérôme Glisse, Jason Gunthorpe, Christoph Hellwig,
	linux-kernel

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(+)

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

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] libnvdimm: Enable unit test infrastructure compile checks
  2019-06-17 20:52 [PATCH] libnvdimm: Enable unit test infrastructure compile checks Dan Williams
@ 2019-06-19 11:23   ` Christoph Hellwig
  0 siblings, 0 replies; 5+ messages in thread
From: Christoph Hellwig @ 2019-06-19 11:23 UTC (permalink / raw)
  To: Dan Williams
  Cc: linux-kernel, Jérôme Glisse, Jason Gunthorpe,
	Christoph Hellwig, linux-nvdimm

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.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] libnvdimm: Enable unit test infrastructure compile checks
@ 2019-06-19 11:23   ` Christoph Hellwig
  0 siblings, 0 replies; 5+ messages in thread
From: Christoph Hellwig @ 2019-06-19 11:23 UTC (permalink / raw)
  To: Dan Williams
  Cc: linux-nvdimm, Jérôme Glisse, Jason Gunthorpe,
	Christoph Hellwig, linux-kernel

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] libnvdimm: Enable unit test infrastructure compile checks
  2019-06-19 11:23   ` Christoph Hellwig
@ 2019-06-19 16:27     ` Dan Williams
  -1 siblings, 0 replies; 5+ messages in thread
From: Dan Williams @ 2019-06-19 16:27 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jérôme Glisse, Jason Gunthorpe,
	Linux Kernel Mailing List, linux-nvdimm

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.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] libnvdimm: Enable unit test infrastructure compile checks
@ 2019-06-19 16:27     ` Dan Williams
  0 siblings, 0 replies; 5+ messages in thread
From: Dan Williams @ 2019-06-19 16:27 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: linux-nvdimm, Jérôme Glisse, Jason Gunthorpe,
	Linux Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-06-19 16:27 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-17 20:52 [PATCH] libnvdimm: Enable unit test infrastructure compile checks Dan Williams
2019-06-19 11:23 ` Christoph Hellwig
2019-06-19 11:23   ` Christoph Hellwig
2019-06-19 16:27   ` Dan Williams
2019-06-19 16:27     ` Dan Williams

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.