On Thu, Apr 03, 2014 at 10:05:26AM -0700, Andy Lutomirski wrote: > > virtme will eventually be able to use a separate OS image, probably in > the form of a directory with appropriate xattrs set. I could support > images on a block device too, but that's boring :) When you say OS image, you mean "root file system, right"? One of the reasons why I'm actually build an actual root-file system image, and didn't try the virtme approach was that I wanted to boot 32-bit kernels on my development machine, which is 64-bit. Having a 32-bit chroot environment would certainly work, though, and would save the effort of creating the root file system image.... (and of course having a 32-bit userspace also is a great way of exercising the ioctl compatibility code paths :-). > from inside a virtme checkout. You'll have to compile xfstests first, though. Fortunately, xfstests-bld will handle do this for you, since it grabs and builds all of the depedencies automatically. More importantly, it allows the dependencies to be saved as part of the test output since that's important when trying to have other people understand how to reproduce a particular test result (since sometimes the latest xfstests requires the latest xfs_io from xfsprogs, so it's a bad idea to depend on the version of xfsprogs shipped by your distribution). For example, for this merge window, I've been using the following to do my tests: fio fio-2.1-19-g0b14f0a (Thu, 23 May 2013 21:27:54 +0200) quota 0d0a674 (Tue, 26 Mar 2013 17:13:33 +0100) xfsprogs v3.2.0-alpha2-60-gaa210c4 (Thu, 13 Mar 2014 21:23:50 +1100) xfstests-bld 1efde7a (Tue, 1 Apr 2014 14:42:07 -0400) xfstests linux-v3.8-336-g3948694 (Thu, 13 Mar 2014 15:20:54 +1100) > They will be considerably more useful once I add read-write host > windows to virtme. Yes, you definitely want that for the results directories. > - There's an undocumented way to write results outside the source > tree called RESULT_BASE. It would be great if it were documented and > spelled consistently. There are a bunch of inconsistencies, which I've chalked up to historical accidents and a desire to not break compatibility with developers' test runners. You mount the $SCRATCH_DIR on SCRATCH_MNT but you mount $TEST_DEV on $TEST_DIR, for example. I've just learned to live with it.... > - SCRATCH_MNT needs to be in /etc/fstab. I think that this should be > changed or documented. If the latter, then SCRATCH_DEV seems > redundant. The various test scripts do need to be able to find the device where the file system lives, and parsing /etc/fstab would be awkward. So if your comment is that either the /etc/fstab entry shouldn't be required, or the xfstests runtime environment should be able to derive $SCRATCH_DEV automatically from $SCRATCH_MNT, or vice versa, instead of having the user specify both, I'd agree that would be nice, but that's why I put together scripts like the ones I have in xfstests-bld --- to make life easier. :-) Cheers, - Ted -- 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
