On Fri, Sep 15, 2017 at 2:18 AM, Johannes Thumshirn [off-list ref] wrote:

On Thu, Sep 14, 2017 at 07:10:02AM -0700, Dan Williams wrote:

quoted

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.

quoted

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.