linux-ext4 - Re: [Lsf] [PATCH] xfstests-bld: Simplify determination of number of CPUs in build-all

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <533DB140.8010103@redhat.com>
Date:	Thu, 03 Apr 2014 13:06:40 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>,
	Andy Lutomirski <luto@...capital.net>
CC:	Lukáš Czerner <lczerner@...hat.com>,
	Dave Chinner <david@...morbit.com>, 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 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

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