On Thu, Sep 14, 2017 at 08:19:58AM -0400, Jeff Moyer wrote: > 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. I think I already said this before [1], but can't we make a "features" sysfs/debugfs attribute with one bit set for each feature implemented? This definitively would help when running the test-suite on a backport. [1] https://lists.01.org/pipermail/linux-nvdimm/2016-March/004963.html Byte, Johannes -- Johannes Thumshirn Storage jthumshirn@xxxxxxx +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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
