On Thu, Sep 14, 2017 at 6:16 AM, Johannes Thumshirn <jthumshirn@xxxxxxx> wrote: > 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 What discouraged me from going that route in the past is the busy work of tracking / syncing these new debugfs feature gate flags across 2 source repositories. If we want to stop depending on kernel version in the test suite over time I think the only sane way to manage that tight integration is to get ndctl into the kernel tree proper. ...but please say a bit more about the actual pain points with the current environment variable approach. You want to be able to have a debugfs directory that has something like: /featureA /featureB /featureC /fixX /fixY /fixZ /quirkQ ...where, depending on backport priorities, a subset of those may not exist? Does having the test suite in the kernel tree help or hurt what you're trying to do? -- 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
