Re: [PATCH] xfs: add regression test for DAX mount option usage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux