Message-ID: <CALCETrU=JWigDSv6ymepS2tjL+EkO98VDC03-RSPuhQVk3yvZA@mail.gmail.com>
Date:	Thu, 3 Apr 2014 10:05:26 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Lukáš Czerner <lczerner@...hat.com>
Cc:	Dave Chinner <david@...morbit.com>,
	"Theodore Ts'o" <tytso@....edu>, xfs@....sgi.com,
	lsf@...ts.linux-foundation.org,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Sedat Dilek <sedat.dilek@...il.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of
 CPUs in build-all

On Thu, Apr 3, 2014 at 3:26 AM, Lukáš Czerner <lczerner@...hat.com> wrote:
> On Thu, 3 Apr 2014, Dave Chinner wrote:
>
>> Date: Thu, 3 Apr 2014 12:14:11 +1100
>> From: Dave Chinner <david@...morbit.com>
>> To: Theodore Ts'o <tytso@....edu>
>> Cc: Sedat Dilek <sedat.dilek@...il.com>, lsf@...ts.linux-foundation.org,
>>     linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org, xfs@....sgi.com
>> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists