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
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
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
(No doubt docs could be improved, but we can do that by sending patches.) :)