Theodore Tso wrote: > On Mon, May 11, 2009 at 05:46:39AM -0400, Christoph Hellwig wrote: >> Last time I brought the idea of a small in-tree test harness up at KS >> people weren't too fond of it, but if we get more backing now we could >> try it, otherwise we can just stick it into xfsqa which will hopefully >> soon be generalized to a general fs QA suite. > > Two questions --- first of all, has there been any progress with > respect to fixing the licensing of the xfsqa tree. (i.e., "All Rights > Reserved" needs to change to a GPLv2 license)? We've had a verbal ack from sgi that it should be under an open-source license. But until that is committed to the repo.... > And would you be open to cleaning up xfsqa by for example, moving some > of the tests out of the top-level directory, adding a modified xfs_io > to xfsqa (modified to not avoid using XFS-specific ioctl whereever > possible), etc. Sure. xfs_io already can act on non-xfs filesystems, although right now it takes a flag to do so. But it can do many ops* that way, and we're open to add more (I just sent a patch to add fallocate yesterday). As for directory layout, whatever works is likely fine. > I've been collecting my own set of test programs for ext4, and I've > thought about trying to use xfsqa, but it's not obvious to me it would > be more or less work, since in many ways there are a lot of places > where a lot of cleanup work and filesystem portability work would be > needed, and it's not clear that creating a new test framework and > collection of tests would be more or less work. Yes, xfsqa would/will take some work to get there I guess. OTOH so much of filesystem testing could be shared, it's a shame to duplicate it for each filesytem, too. > (For example, of cleanup that I'd love to see, I'd really like to use > real names for tests and not just random three digit numbers like 107, > 108, 109, all cluterring the top-level directory along with 107.out, > 108.out, 109.out, etc.) Well they're not random, they are sequential ;) But yeah at least giving each test a description (at least a DESCRIPTION="tests fubarbaz") would be helpful. > Of course, until the copyright/licensing situation is cleared up, all > of these other issues are rather moot.... I'll press SGI on this... -Eric > - Ted *fadvise, file, print, freeze, thaw, fsync, fdatasync, getrusage, madvise, mincore, mmap, mread, msync, munmap, mwrite, open, stat, close, setfl, statfs, pread, pwrite, sendfile, truncate -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
