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? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
