On Fri, Sep 15, 2017 at 2:18 AM, Johannes Thumshirn <jthumshirn@xxxxxxx> wrote: > On Thu, Sep 14, 2017 at 07:10:02AM -0700, Dan Williams wrote: >> 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. > > This means the person which executes the test-suite has to know on which > feature level (upstream kernel version) the downstream kernel is, I can't > demand such knowledge from QA. Ok, that makes sense. The libnvdimm unit test suite needs to grow up into something QA can run and not require developers with internals knowledge. > >> 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? > > Yes, I thought of a bitmask in one (or two files but a file per feature is OK) > as well. The idea is borrowed from Daniel Vetter's "Bothing up ioctl()s" blog > entry [1]: > "Have a clear way for userspace to figure out whether your new ioctl or ioctl > extension is supported on a given kernel. If you can't rely on old kernels > rejecting the new flags/modes or ioctls (since doing that was botched in the > past) then you need a driver feature flag or revision number somewhere." > Yes, but what we're worried about in the libnvdimm/nfit_test case is internals behind sysfs interfaces. But point taken, we can at least use the presence of certain attributes to gate tests. However, it does mean we lose the tests for when an attribute is missing due to an incomplete backport. -- 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
