All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>, Andy Lutomirski <luto@amacapital.net>
Cc: "Lukáš Czerner" <lczerner@redhat.com>,
	"Dave Chinner" <david@fromorbit.com>,
	xfs@oss.sgi.com, lsf@lists.linux-foundation.org,
	"Linux FS Devel" <linux-fsdevel@vger.kernel.org>,
	"Sedat Dilek" <sedat.dilek@gmail.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of CPUs in build-all
Date: Thu, 03 Apr 2014 13:06:40 -0600	[thread overview]
Message-ID: <533DB140.8010103@redhat.com> (raw)
In-Reply-To: <20140403173504.GB23737@thunk.org>

On 4/3/14, 11:35 AM, Theodore Ts'o wrote:

>>  - 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.

I'm not actually certain that it was intended to be used this way.
See 1686f9ab "xfstests: Introduce a results directory" 
which explains just where this variable came from and what it's
for...

So that's probably why it's undocumented; I don't think it was
envisioned as a configurable.  As for consistency... patch
sent for the typo.

If the functionality is needed, just make sure it works right if
you set it manually, update the user docs, & send a patch.

> 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

$SCRATCH_DEV you mean. ;)  I don't think there's any real resistance
to fixing things that really need to be fixed, but this one
doesn't seem too critical.  OTOH, adding an alias from SCRATCH_MNT
to SCRATCH_DIR for consistency could surely be done if anyone cared
enough to send the patch.

> 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.

Hm, I've never needed SCRATCH_MNT in /etc/fstab... 

> 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

I guess I don't know why you'd expect to derive one from the other...

> 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.  :-)

All I've ever had to do is set up the 4 variables in local.config.example
(by copying to local.config & editing appropriately) and it all just works
AFAIK.

(No doubt docs could be improved, but we can do that by sending patches.)  :)

-Eric


WARNING: multiple messages have this Message-ID (diff)
From: Eric Sandeen <sandeen@redhat.com>
To: Theodore Ts'o <tytso@mit.edu>, Andy Lutomirski <luto@amacapital.net>
Cc: xfs@oss.sgi.com, lsf@lists.linux-foundation.org,
	"Linux FS Devel" <linux-fsdevel@vger.kernel.org>,
	"Sedat Dilek" <sedat.dilek@gmail.com>,
	"Lukáš Czerner" <lczerner@redhat.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of CPUs in build-all
Date: Thu, 03 Apr 2014 13:06:40 -0600	[thread overview]
Message-ID: <533DB140.8010103@redhat.com> (raw)
In-Reply-To: <20140403173504.GB23737@thunk.org>

On 4/3/14, 11:35 AM, Theodore Ts'o wrote:

>>  - 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.

I'm not actually certain that it was intended to be used this way.
See 1686f9ab "xfstests: Introduce a results directory" 
which explains just where this variable came from and what it's
for...

So that's probably why it's undocumented; I don't think it was
envisioned as a configurable.  As for consistency... patch
sent for the typo.

If the functionality is needed, just make sure it works right if
you set it manually, update the user docs, & send a patch.

> 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

$SCRATCH_DEV you mean. ;)  I don't think there's any real resistance
to fixing things that really need to be fixed, but this one
doesn't seem too critical.  OTOH, adding an alias from SCRATCH_MNT
to SCRATCH_DIR for consistency could surely be done if anyone cared
enough to send the patch.

> 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.

Hm, I've never needed SCRATCH_MNT in /etc/fstab... 

> 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

I guess I don't know why you'd expect to derive one from the other...

> 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.  :-)

All I've ever had to do is set up the 4 variables in local.config.example
(by copying to local.config & editing appropriately) and it all just works
AFAIK.

(No doubt docs could be improved, but we can do that by sending patches.)  :)

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2014-04-03 19:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-28  9:03 [PATCH] xfstests-bld: Simplify determination of number of CPUs in build-all Sedat Dilek
2014-03-28 16:18 ` tytso
2014-03-29 10:04   ` Sedat Dilek
2014-03-29 14:04     ` Theodore Ts'o
2014-03-31  2:51   ` [Lsf] " Dave Chinner
2014-04-01  2:37     ` Theodore Ts'o
2014-04-01  2:37       ` Theodore Ts'o
2014-04-01 22:28       ` Dave Chinner
2014-04-01 22:28         ` Dave Chinner
2014-04-02 14:26         ` Theodore Ts'o
2014-04-03  1:14           ` Dave Chinner
2014-04-03  1:14             ` Dave Chinner
2014-04-03 10:26             ` Lukáš Czerner
2014-04-03 17:05               ` Andy Lutomirski
2014-04-03 17:35                 ` Theodore Ts'o
2014-04-03 17:35                   ` Theodore Ts'o
2014-04-03 17:42                   ` Andy Lutomirski
2014-04-03 17:42                     ` Andy Lutomirski
2014-04-03 19:06                   ` Eric Sandeen [this message]
2014-04-03 19:06                     ` Eric Sandeen
2014-04-03 19:21                     ` Andy Lutomirski
2014-04-03 19:21                       ` Andy Lutomirski
2014-04-03 21:46                       ` Eric Sandeen
2014-04-03 19:30                     ` Theodore Ts'o
2014-04-03 21:20                       ` Dave Chinner
2014-04-03 13:16           ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=533DB140.8010103@redhat.com \
    --to=sandeen@redhat.com \
    --cc=david@fromorbit.com \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf@lists.linux-foundation.org \
    --cc=luto@amacapital.net \
    --cc=sedat.dilek@gmail.com \
    --cc=tytso@mit.edu \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.