On Wed, Sep 13, 2017 at 5:40 PM, Dave Chinner <da...@fromorbit.com> wrote: > On Wed, Sep 13, 2017 at 05:28:39PM -0700, Dan Williams wrote: >> On Wed, Sep 13, 2017 at 4:34 PM, Dave Chinner <da...@fromorbit.com> wrote: >> > /me shrugs >> > >> > I just don't like the concept of using tracepoints to as a >> > definitive diagnostic test for something working because it'll break >> > when the kernel implementation and tracepoints change. So while we >> > can probe for perf being present, we can't probe whether the >> > tracepoint we need behaves as the test expects it to... >> >> That concern makes sense. >> >> We handle that it a crude way in the libnvdimm unit tests by hard >> coding a required minimum kernel version and rolling a test forward to >> depend on a new kernel when assumptions about the kernel-internals >> change. The tests also inject out-of-tree kernel modules that let us >> go after specific kernel internal behavior. With this approach we >> don't end up creating userspace ABI since the test explicitly loads >> out-of-tree modules. > > That's horrible. OT, but how are distros or anyone backporting > libnvdimm fixes and features supposed to test their kernels work > correctly with such a test harness?
The upstream kernel version for the test to assume can be overridden by an environment variable. It has worked well so far for me when I'm using it it to test backports, but I don't have much in the way of third-party feedback. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
