On Thu, Apr 3, 2014 at 3:26 AM, Lukáš Czerner <lczerner@xxxxxxxxxx> wrote: > On Thu, 3 Apr 2014, Dave Chinner wrote: > >> Date: Thu, 3 Apr 2014 12:14:11 +1100 >> From: Dave Chinner <david@xxxxxxxxxxxxx> >> To: Theodore Ts'o <tytso@xxxxxxx> >> Cc: Sedat Dilek <sedat.dilek@xxxxxxxxx>, lsf@xxxxxxxxxxxxxxxxxxxxxxxxxx, >> linux-ext4@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx >> Subject: Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of >> CPUs in build-all >> >> On Wed, Apr 02, 2014 at 10:26:20AM -0400, Theodore Ts'o wrote: >> > On Wed, Apr 02, 2014 at 09:28:23AM +1100, Dave Chinner wrote: >> > > > And of course, whether changes in the mainline kernel tree are >> > > > manually propagated changes from the xfstests.git tree, or whether >> > > > primary development happens in the kernel tree, is ultimately going to >> > > > be up to you and the XFS developers who have stewardship of xfstests. >> > > > I'm not sure I would be that excited about manual propagation of >> > > > changes from one git tree to another, but that is of course, up to >> > > > you. >> > > >> > > And this is exactly my point, Ted. Again, you are presuming that the >> > > implementation is going to require syncing commits across disparate >> > > git trees and other such games will be needed to maintain separate >> > > packages. Nothing could be further from the truth: we already have >> > > this problem with the shared XFS kernel/userspace code and it's a >> > > royal PITA keeping them in sync. Hence introducing the same >> > > maintenance problem with new code and infrastructure is highly >> > > undesirable and something we'll try to avoid at all costs. >> > >> > Actually, I was presuming that the thing that makes the most sense was >> > to move all or most of the tests in xfstests into the kernel tests >> > tree. And then you complained that I was making a presumption that >> > this was the only sane thing to do. That's why I said, "if you want >> > to do something insane, be my guest". >> >> So, you think there's only one "sane" solution. That's a massive >> assumption, and that's what I'm pointing out. >> >> It's perfectly sane to treat the kernel tree as just another >> downstream consumer of xfstests, and simple add infrastructure to >> the kernel tree to source and build xfstests from the upstream repo. > > That's what I think is the best approach as well. We'll still have > separate tree for the xfstests which works for everyone and > infrastructure in kernel tree which will simply use it. > > Looking at rcutorture tests in kernel tree, they are indeed using > qemu and it looks like that they are running those tests directly > from init script - we really need an image to boot from. > > We could use virtme > > https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/ 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 :) > > which seems like a best option. Alternatively we could allow users > passing their own image as well. > > Then we would need init script which would download and build > xfstests, xfsprogs and possible other dependencies (such as fio) > and finally run xfstests itself. Colnsole output from the qemu can > be redirected to the file in the host, so that's ok, but we still > need a way to retrieve 'retults' directory from the test. > > We'd also need a devices to test on (at least TEST_DEV and > SCRATCH_DEV). Those could be files a of set size exported to qemu as > block devices. I just pushed a pair of sample scripts that invokes xfstests inside virtme. They're a total of 42 lines, including comments and instructions. You can now do: PATH=.:$PATH samples/xfstests test.img scratch.img ~/apps/xfstests/ from inside a virtme checkout. You'll have to compile xfstests first, though. They will be considerably more useful once I add read-write host windows to virtme. If anyone wants to use virtme for something other than experimentation, let me know and we can talk about interface stability. Some xfstests thoughts: - 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. - xfstests does not appreciate using symlinks to device nodes. - 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. Some virtme thoughts: - --script-sh is awkward. Suggestions for a better interface are welcome. - It would be great if the virtconsole driver were less buggy. Even the virtualized ttyS0 is slow enough to account for a significant fraction of boot time. It would also be great if the connection between virtio ports and hvc devices were exposed in sysfs and through /dev symlinks. - earlyprintk=virtconsole would be awesome. This might need help from qemu, though. Or maybe there's a way to get the debug port to work for that. - I should probably add simple way to use forcibly cached disks. --Andy -- 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
