Dan Williams <dan.j.williams@xxxxxxxxx> writes: > On Wed, Sep 13, 2017 at 5:40 PM, Dave Chinner <david@xxxxxxxxxxxxx> 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 <david@xxxxxxxxxxxxx> 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. It sucks. :-) What we really want is to depend on a feature being available, not on a kernel version. We did discuss this a while ago. Let me go dig it up... https://lists.01.org/pipermail/linux-nvdimm/2017-March/009253.html We never came to any real conclusion on a good way forward, though. Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
