On Thu, Apr 3, 2014 at 10:35 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > 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. > Yes. I've actually done this to test some vdso stuff. > 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 :-). I agree, as long as there are giant quote marks around chroot. No actual chroot would be involved. I'd like to support non-x86 architectures, too. Last time I tried to convince a modern kernel to boot on a released QEMU on ARM was painful, though. Maybe -M virt is the way to go here. The tricky part here is that virtme currently relies on finding a statically-linked busybox binary in $PATH. It'll need to learn how to find one that will run on the guest, or it will need to learn how to live without busybox. > >> 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) I haven't actually looked at xfstests-bld yet. I suspect it could be made to work with virtme fairly easily. My current hack uses assumes you'll use distro packages for all the dependencies. > >> 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.... Given that RESULTS_BASE only occurs in an error message, I think it could be fixed without breaking compatibility. > >> - 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 -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
