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. > 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." > Does having the test suite in the kernel tree help or hurt what > you're trying to do? Having the test suite in the kernel is problematic when you want to distribute it to somewhere. I can only talk about my workflow here, but I build an rpm on my build server and then scp it to my test host. With the current test-suite I have to bring the other modules over as well and install them before the kernel rpm to have the linker wrapper trick working. That's OKish for developer testing, but for QA (or even testing at partners or customers) this gets cumbersome and I really want to have even end customers being able to run the test-suite to verify their kernel is working properly. [1] http://blog.ffwll.ch/2013/11/botching-up-ioctls.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
