[PATCH] [xfstests-bld] Remove redundant gce-xfstests documentation

[PATCH] [xfstests-bld] Remove redundant gce-xfstests documentation

[Eric Biggers]

README.GCE is no longer necessary because the same information, with
more details, can now be found in gce-xfstests.md.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 kvm-xfstests/README.GCE | 147 ------------------------------------------------
 1 file changed, 147 deletions(-)
 delete mode 100644 kvm-xfstests/README.GCE

diff --git a/kvm-xfstests/README.GCE b/kvm-xfstests/README.GCE
deleted file mode 100644
index 8634572..0000000
--- a/kvm-xfstests/README.GCE
+++ /dev/null
@@ -1,147 +0,0 @@
-
-	      Running xfstests on Google Compute Engine
-
-Getting a Google Compute Engine account
----------------------------------------
-
-If you don't have GCE account, you can go to https://cloud.google.com
-and sign up for a free trial.  This will get you $300 dollars worth of
-credit which you can use over a 60 day period (as of this writing).
-Given that a full test costs around a $1.50, and a smoke test costs
-pennies, that should be enough for plenty of testing.  :-)
-
-Configuration
--------------
-
-You will need to set up the following configuration parameters in
-~/.config/kvm-xfststs:
-
-GS_BUCKET	The name of the Google Storage bucket which should be
-		used by gce-xfstests.  Your Google Compute Engine account
-		must have access to read and write files in this bucket.
-
-GCE_PROJECT	The name of Google Compute Engine project which should
-		be used to create and run GCE instances and disks.
-
-GCE_ZONE	The name of the Google Compute Engine zone which should
-		be used by xfstests.
-
-GCE_KERNEL	The pathname to kernel that should be used for gce-xfstests
-		by default.
-
-If you have a sendgrid account, you can set the following
-configuration parameters in order to have reports e-mailed to you:
-
-GCE_SG_USER	The username for the sendgrid account used to send email
-
-GCE_SG_PASS	The password for the sendgrid account used to send email
-
-GCE_REPORT_EMAIL The email addressed for which test results should be
-sent.
-
-An example ~//.config/kvm-xfstests might look like this:
-
-GS_BUCKET=tytso-xfstests
-GCE_PROJECT=tytso-linux
-GCE_ZONE=us-central1-c
-GCE_KERNEL=/build/ext4-64/arch/x86/boot/bzImage
-
-
-Creating the image
-------------------
-
-You will need to install the following packages (debian package names
-used):
-
-	jq xz-utils git autoconf2.59 libtool-bin automake libc6-dev
-	gcc make e2fslibs-dev pkg-config gettext libpopt-dev
-
-You will also need to install the Google Cloud SDK.
-
-1)  make ; make tarball
-
-2)  cd kvm-xfstests/test-appliance ; ./gce-create-image
-
-Running gce-xfstests
---------------------
-
-Running gce-xfstests is much like kvm-xfstests; see the README file in
-this directory for more details.
-
-The gce-xfstests command also has a few other commands:
-
-gce-xfstests ssh INSTANCE
-
-	Remotely login as root to a test instances.  This is a
-	convenience shorthand for: "gcloud compute --project
-	GCE_PROJECT ssh root@INSTNACE --zone GCE_ZONE".
-
-gce-xfstests console INSTANCE
-
-	Fetch the serial console from a test instance.  This is a
-	convenience shorthand for: "gcloud compute --project
-	GCE_PROJECT get-serial-port-output INSTANCE --zone GCE_ZONE".
-
-gce-xfstests ls-instances [-l ]
-gce-xfstests ls-gce
-
-	List the current test instances.  With the -l option, it will
-	list the current status of each instance.
-
-	The ls-gce option is a convenience command for "gcloud compute
-	--project GCE_PROJECT instances list --regexp ^xfstests.*"
-
-	ALIAS: gce-xfstests ls
-
-gce-xfstests rm-instances INSTANCE
-gce-xfstests abort-instances INSTANCE
-
-	Shut down the instance.  The abort command will delete make
-	sure the results disk to be deleted.  If test kernel has hung,
-	it may be useful to use "gce-xfstests console" to fetch the
-	console, and then use "gce-xfstests rm" and examine the
-	results disk before deleting it.
-
-	ALIAS: gce-xfstests rm
-	ALIAS: gce-xfstests abort
-
-gce-xfstests ls-disks
-
-	List the GCE disks.  This is a convenience command for "gcloud
-	compute --project "$GCE_PROJECT" disks list --regexp
-	^xfstests.*"
-
-	ALIAS: gce-xfstests ls-disk
-
-gce-xfstests rm-disks DISK
-
-	Delete a specified GCE disk.  This is a convenience command
-	for "gcloud compute --project "$GCE_PROJECT" disks delete DISK"
-
-ALIAS: gce-xfstests rm-disk
-
-gce-xfstests ls-results
-gce-xfstests ls-gcs
-
-	List the available results tarballs stored in the Google Cloud
-	Storage bucket.  This is a convenience command for
-	"gsutil ls gs://GS_BUCKET/results.*" (ls-results) or
-	"gsutil ls gs://GS_BUCKET" (ls-gcs).
-
-gce-xfstests rm-results RESULT_FILE
-
-	Delete a specified result tarball.  This is a convenience
-	command for "gsutil ls gs://GS_BUCKET/RESULT_FILE".
-
-gce-xfstests get-results [--unpack | --summary | --failures ] RESULT_FILE
-
-	Fetch the run-tests.log file from the RESULT_FILE stored in
-	the Google Cloud Storage bucket.  The --summary or --failures
-	option will cause the log file to be piped into the
-	"get-results" script to summarize the log file using the "-s"
-	or "-F" option, respectively.  The "--failures" or "-F" option
-	results in a more succint summary than the "--summary" or "-s"
-	option.
-
-	The --unpack option will cause the complete results directory
-	to be unpacked into a directory in /tmp instead.
-- 
2.8.0.rc3.226.g39d4020

[PATCH] [xfstests-bld] Fix typos in xfstests-bld documentation

[Eric Biggers]

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 Documentation/building-rootfs.md   |  8 ++++----
 Documentation/building-xfstests.md |  8 ++++----
 Documentation/gce-xfstests.md      | 22 +++++++++++-----------
 Documentation/kvm-quickstart.md    | 23 ++++++++++++-----------
 Documentation/kvm-xfstests.md      | 19 ++++++++++---------
 Documentation/what-is-xfstests.md  |  8 ++++----
 README                             |  4 ++--
 kvm-xfstests/util/parse_cli        |  4 ++--
 8 files changed, 49 insertions(+), 47 deletions(-)

diff --git a/Documentation/building-rootfs.md b/Documentation/building-rootfs.md
index 863a755..8665919 100644
--- a/Documentation/building-rootfs.md
+++ b/Documentation/building-rootfs.md
@@ -3,7 +3,7 @@
 The root_fs.img file is used as the test appliance VM for
 kvm-xfstests.  It consists of a Debian Jessie root file system, some
 configuration files and test runner scripts, and the xfstests.tar.gz
-unpacked in the the /root directory.  It is built using the gen-image
+unpacked in the /root directory.  It is built using the gen-image
 script found in kvm-xfstests/test-appliance.
 
 The gen-image script must be run as root, as it creates a file system
@@ -20,16 +20,16 @@ kvm-xfstests/test-appliance/debs.  This is how the official packages
 on kernel.org have an updated version of e2fsprogs and its support
 packages (e2fslibs, libcomerr2, and libss2).  The latest versions get
 compiled for Debian Jessie, in a hermetic build environment, and
-placed in the debs directory.  Optioanlly, the output of the script
+placed in the debs directory.  Optionally, the output of the script
 [get-ver](https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/util/get-ver)
 is placed in the e2fsprogs.ver in the top-level directory of
-xfstests-bld.  This gets incorprated into the git-versions file found
+xfstests-bld.  This gets incorporated into the git-versions file found
 in the xfstests.tar.gz file, so that there will be a line like this in
 the file:
 
         e2fsprogs       v1.43.1-22-g25c4a20 (Wed, 8 Jun 2016 18:11:27 -0400)
 
-If you don't want to compile your own, very lastest, version of
+If you don't want to compile your own, very latest version of
 e2fsprogs, there is a newer version of e2fsprogs, compiled for the
 Debian Jessie distribution,
 [available](https://packages.debian.org/jessie-backports/admin/e2fsprogs)
diff --git a/Documentation/building-xfstests.md b/Documentation/building-xfstests.md
index 640451c..7de4aa2 100644
--- a/Documentation/building-xfstests.md
+++ b/Documentation/building-xfstests.md
@@ -2,7 +2,7 @@
 
 The xfstests-bld package makes it easy to build xfstests in a hermetic
 build environment (so it is not dependent on possibly out-of-date
-distro versions of libaio, xfsprogs, etc.).  This was the original 
+distro versions of libaio, xfsprogs, etc.).  This was the original
 raison d'etre for xfstests-bld, which explains why it was so named.
 
 ## Fetching the external git trees
@@ -45,7 +45,7 @@ needed.  They can be installed using the command:
 1.  Run "make clean"
 
 2.  Run "make".  This will run autoconf (if necessary) in the various
-subcompoents, run "make" or the equivalent to build all of the
+subcomponents, run "make" or the equivalent to build all of the
 subcomponents, and then finally run "make install" to install the
 build artifacts into the bld directory.  The actual work is done via
 the "build-all" script.
@@ -145,8 +145,8 @@ for the Debian armhf platform.
 
 The TOOLCHAIN_DIR shell variable can be used to specify the location
 for the alternate compiler toolchain if it is not your path.  For
-example, let's assume you've install the Android Native Delevelopment
-Toolkit (NDK) and used the make-standalone-toolchain.sh to install a
+example, let's assume you've installed the Android Native Development
+Kit (NDK) and used the make-standalone-toolchain.sh to install a
 toolchain in /u1/arm64-toolchain.  (See the [Android NDK
 documentation](https://developer.android.com/ndk/guides/standalone_toolchain.html)
 for more information.)  To use the standalone toolchain designed for
diff --git a/Documentation/gce-xfstests.md b/Documentation/gce-xfstests.md
index b0c0096..c677f3f 100644
--- a/Documentation/gce-xfstests.md
+++ b/Documentation/gce-xfstests.md
@@ -12,10 +12,10 @@ need to do a number of setup tasks:
 ## Get a Google Compute Engine account
 
 If you don't have GCE account, you can go to https://cloud.google.com
-and sign up for a free trial.  This will get you $300 dollars worth of
-credit which you can use over a 60 day period (as of this writing).
-Given that a full test for ext4 costs around a $1.50, and a smoke test
-costs pennies, that should be enough for plenty of testing.  :-)
+and sign up for a free trial.  This will get you $300 worth of credit
+which you can use over a 60 day period (as of this writing).  Given
+that a full test for ext4 costs around $1.50, and a smoke test costs
+pennies, that should be enough for plenty of testing.  :-)
 
 ### Setting up a GCE project
 
@@ -46,7 +46,7 @@ test VM's so that you don't have unexpected charges to your account.
 The gce-xfstests system needs a Google Cloud Storage (GCS) bucket to
 send kernel images to be tested and to save the results from the test
 runs.  If you are already using GCS you can use a pre-existing
-bucket, but it is strongly adviseable that you use a dedicated bucket
+bucket, but it is strongly advisable that you use a dedicated bucket
 for this purpose.  Detailed instructions for creating a new bucket can
 be found in the [GCS
 Quickstart](https://cloud.google.com/storage/docs/quickstart-console).
@@ -127,7 +127,7 @@ used):
 ## Configure gce-xfstests
 
 You will need to set up the following configuration parameters in
-~/.config/gce-xfststs:
+~/.config/gce-xfstests:
 
 * GS_BUCKET
   * The name of the Google Storage bucket which should be used by
@@ -219,7 +219,7 @@ are described below:
 
 Remotely login as root to a test instances.  This is a
 convenience shorthand for: "gcloud compute --project
-GCE_PROJECT ssh root@INSTNACE --zone GCE_ZONE".
+GCE_PROJECT ssh root@INSTANCE --zone GCE_ZONE".
 
 ### gce-xfstests console INSTANCE
 
@@ -287,7 +287,7 @@ Storage bucket.  This is a convenience command for
 ### gce-xfstests rm-results RESULT_FILE
 
 Delete a specified result tarball.  This is a convenience
-command for "gsutil ls gs://GS_BUCKET/RESULT_FILE".
+command for "gsutil rm gs://GS_BUCKET/RESULT_FILE".
 
 ### gce-xfstests get-results [--unpack | --summary | --failures ] RESULT_FILE
 
@@ -296,7 +296,7 @@ the Google Cloud Storage bucket.  The --summary or --failures
 option will cause the log file to be piped into the
 "get-results" script to summarize the log file using the "-s"
 or "-F" option, respectively.  The "--failures" or "-F" option
-results in a more succint summary than the "--summary" or "-s"
+results in a more succinct summary than the "--summary" or "-s"
 option.
 
 The --unpack option will cause the complete results directory
@@ -315,11 +315,11 @@ was created (in this case, August 13, 2016 at 22:26).
 
 This image will be created as part of an image family called xfstests.
 By default, when you start a test using gce-xfstests, the most
-recently created image in the xfstests image faily will be used.
+recently created image in the xfstests image family will be used.
 
 In order to use the xfstests image family created in your GCE project
 (instead of the xfstests-cloud project), add the following to your
-`/.config/gce-xfstests configuration file after the GCE_PROJECT
+`~/.config/gce-xfstests` configuration file after the GCE_PROJECT
 variable is defined:
 
         GCE_IMAGE_PROJECT="$GCE_PROJECT"
diff --git a/Documentation/kvm-quickstart.md b/Documentation/kvm-quickstart.md
index 0862ab4..94829c6 100644
--- a/Documentation/kvm-quickstart.md
+++ b/Documentation/kvm-quickstart.md
@@ -5,17 +5,18 @@
         apt-get install qemu-kvm
 
 2.  Run the following commands to install the xfstests-bld repository
-and download a pre-compiled test 6appliance image.  We use the 32-bit
-test appliance here since it can support both 32-bit and 64-bit kernels.
+    and download a pre-compiled test appliance image.  We use the
+    32-bit test appliance here since it can support both 32-bit and
+    64-bit kernels.
 
         git clone git://git.kernel.org/pub/scm/fs/ext2/xfstests-bld.git fstests
         cd fstests/kvm-xfstests
         wget -O test_appliance/root_fs.img https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/root_fs.img.i386
 
-3.  Build a kernel with all of the necessary drives for kvm built into
-    the kernel.  No modules should be used, since kvm-xfstests will
-    run the kernel directly from the build tree. This means that there
-    is no need to install any modules or create an initrd, which
+3.  Build a kernel with all of the necessary drivers for kvm built
+    into the kernel.  No modules should be used, since kvm-xfstests
+    will run the kernel directly from the build tree. This means that
+    there is no need to install any modules or create an initrd, which
     significantly speeds up the edit, compile, test, debug development
     cycle.  There are sample 32-bit and 64-bit kernels in the
     kernel-configs directory; pick one whose version number is close
@@ -31,11 +32,11 @@ test appliance here since it can support both 32-bit and 64-bit kernels.
         TZ=America/New_York
         KERNEL=/build/ext4/arch/x86/boot/bzImage
 
-6.  In the top-level directory of your checked outxfstests-git
-repository, run "make kvm-xfstests.sh" and then copy this generated
-file to a directory which is your shell's PATH.  This allows you to
-run the kvm-xfstests binary without needing to set the working
-directory to the kvm-tests directory.
+6.  In the top-level directory of your checked out xfstests-bld
+    repository, run "make kvm-xfstests.sh" and then copy this
+    generated file to a directory which is your shell's PATH.  This
+    allows you to run the kvm-xfstests binary without needing to set
+    the working directory to the kvm-xfstests directory.
 
         cd fstests
         make kvm-xfstests.sh
diff --git a/Documentation/kvm-xfstests.md b/Documentation/kvm-xfstests.md
index b85bb7e..c480e4a 100644
--- a/Documentation/kvm-xfstests.md
+++ b/Documentation/kvm-xfstests.md
@@ -41,8 +41,9 @@ Please see the relevant documentation files for more details.
 The configuration file for kvm-xfstests is found in the kvm-xfstests
 directory and is named config.  You can edit this file directly, but
 the better thing to do is to place override values in
-~/config/kvm-xfstests or in kvm-xfststs/config.custom.  Please look at
-the kvm-xfstests/config file to see the shell variables you can set.
+~/.config/kvm-xfstests or in kvm-xfstests/config.custom.  Please look
+at the kvm-xfstests/config file to see the shell variables you can
+set.
 
 Perhaps the most important configuration variable to set is KERNEL.
 This should point at the default location for the kernel that qemu
@@ -51,8 +52,8 @@ primary build tree that you use for kernel development.  Please use as
 the base for the .config file one of the kernel configurations from
 the kernel-config directory.  It is important that the kernel have all
 of the paravirtual device driver support needed for qemu included in
-the base kernel, since any modules will be ignored, and test appliance
-does not use an initial ramdisk.
+the base kernel, since any modules will be ignored, and the test
+appliance does not use an initial ramdisk.
 
 By default, the scratch disks used by test-appliance will be set up
 automatically, and are stored in the kvm-xfstests directory with the
@@ -86,8 +87,8 @@ kvm-xfstests/kvm-xfstests shell script.
 
 Please run "kvm-xfstests help" to get a quick summary of the available
 command-line syntax.  Not all of the available command-line options
-are documented; some of the more specialized optiosn will require that
-you Read The Fine Source --- in particular, in the auxliary script
+are documented; some of the more specialized options will require that
+you Read The Fine Source --- in particular, in the auxiliary script
 file found in kvm-xfstests/util/parse_cli.
 
 ### Running file system tests
@@ -114,8 +115,8 @@ which runs a subset of the tests designed for a fast smoke test.
 For developer convenience, "kvm-xfstests smoke" is short-hand for
 "kvm-xfstests -c 4k -g quick", which runs the fast subset of tests
 using just 4k block file system configuration.  In addition
-"kvm-xfstests full" is short-hand for "kvm-xfstests -g quto" which
-runs all of the tests using a large set of file system configuration.
+"kvm-xfstests full" is short-hand for "kvm-xfstests -g auto" which
+runs all of the tests using a large set of file system configurations.
 This will take quite a while, so it's best run overnight.  (Or it may
 be better to run the full set of tests using gce-xfstests.)
 
@@ -151,7 +152,7 @@ While kvm-xfstests is running, you can telnet to a number of TCP ports
 (which are bound to localhost).  Ports 7500, 7501, and 7502 will
 connect you to a shell prompts while the tests are running (if you
 want to check on /proc/slabinfo, enable tracing, etc.)  You can also
-use these ports in conjuction with "kvm-xfstests shell" if you want
+use these ports in conjunction with "kvm-xfstests shell" if you want
 additional windows to capture traces using ftrace.
 
 You can also access the qemu monitor on port 7498, and you can debug the
diff --git a/Documentation/what-is-xfstests.md b/Documentation/what-is-xfstests.md
index 1ad3cb7..8bdf7ea 100644
--- a/Documentation/what-is-xfstests.md
+++ b/Documentation/what-is-xfstests.md
@@ -13,12 +13,12 @@ will run a full set of xfstests before sending patches to Linus, and
 will require that any major changes be tested using xfstests before
 they are submitted for integration.
 
-## Individal tests in xfstests
+## Individual tests in xfstests
 
 Tests in xfstests were originally named using a three digit number.
 In 2013 the tests were moved into different classes, depending on
 whether the test was file system specific, "generic" (meaning it was
-was file system indepedent), or "shared" (meaning that test was not
+was file system independent), or "shared" (meaning that test was not
 truly generic, but which was useful on a handful of file systems).  In
 this scheme, tests would have names such as:
 
@@ -77,9 +77,9 @@ sometimes called the TEST-1K device -- although there are many other
 file system configurations which will use /dev/vdd.
 
 The /dev/vde and /dev/vdf file systems are the BIGTEST and BIGSCRATCH
-disks, and are used for those file system configrations which require
+disks, and are used for those file system configurations which require
 a 20GB TEST and SCRATCH device.  Like the TEST-1K device, the BIGTEST
-device will be reformated using mke2fs at the beginning of an xfstests
+device will be reformatted using mke2fs at the beginning of an xfstests
 run for that file system configuration.
 
 The gce-xfstests uses the same set of block devices, although instead
diff --git a/README b/README
index ee1ba0f..ef87668 100644
--- a/README
+++ b/README
@@ -16,7 +16,7 @@ and create something which works for your distribution.  Please let me
 know if create something which works well for other distributions.
 
 1.  "make ; make tarball" to generate the xfstests.tar.gz file.
-2.  cd to kvm-xfststs/test-appliance, and run as root the shell script
+2.  cd to kvm-xfstests/test-appliance, and run as root the shell script
     "gen-image".  This will create the root_fs.img file.
 3.  build a kernel which does not use modules (at least for all of the
     device drivers required for running under kvm).  There are sample
@@ -25,7 +25,7 @@ know if create something which works well for other distributions.
     to build the root_fs.img file in 32-bit build chroot.  You can use
     a 32-bit userspace with a 64-bit kernel; in fact, this is a good
     way to sanity check the ioctl compatibility code.
-4.  Adjust the KERNEL= line in kvm-xfststs/config to point at your
+4.  Adjust the KERNEL= line in kvm-xfstests/config to point at your
     kernel's bzImage file.
 5.  cd to kvm-xfstests, and run "kvm-xfstests smoke".  More details of
     how to run kvm-xfstests can be found in kvm-xfstests/README.  If
diff --git a/kvm-xfstests/util/parse_cli b/kvm-xfstests/util/parse_cli
index 84f5761..6dae32f 100644
--- a/kvm-xfstests/util/parse_cli
+++ b/kvm-xfstests/util/parse_cli
@@ -43,12 +43,12 @@ print_help ()
     echo "xfstest names have the form: ext4/NNN generic/NNN shared/NNN"
     echo ""
     if test "$GCE_XFSTESTS" = "yes" ; then
-	echo "Common gce-xfststs commands:"
+	echo "Common gce-xfstests commands:"
         echo "	ls		- List running xfstests instances"
         echo "	abort		- Abort a xfstests instance"
         echo "	ls-results	- List saved test results"
         echo "	get-results	- Get and display a specified test result"
-        echo "	setup		- Set up gce-xfststs (only needs to be run once)"
+        echo "	setup		- Set up gce-xfstests (only needs to be run once)"
         echo "	ssh		- Login to a running test instance"
         echo "	console		- Get the console messages from a test instance"
         echo "	serial		- Attach to the serial port of a test instance"
-- 
2.8.0.rc3.226.g39d4020

[PATCH] [xfstests-bld] kvm-xfstests: forbid conflicting specifications of FSTESTCFG

[Eric Biggers]

It was possible to run kvm-xfstests with arguments like '-c encrypt
smoke', in which case FSTESTCFG ended up set to "4k" because 'smoke'
implies '-c 4k' and the second config specification overrode the first.
If the user tries something like this, fail with a helpful error message
rather than proceeding with a configuration that likely wasn't intended.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 kvm-xfstests/util/parse_cli | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/kvm-xfstests/util/parse_cli b/kvm-xfstests/util/parse_cli
index 6dae32f..a170931 100644
--- a/kvm-xfstests/util/parse_cli
+++ b/kvm-xfstests/util/parse_cli
@@ -1,6 +1,6 @@
 #!/bin/bash
 
-FSTESTCFG=all
+FSTESTCFG=""
 SNAPSHOT=",snapshot=on"
 DO_AEX="yes"
 API="1.3"
@@ -118,6 +118,12 @@ while [ "$1" != "" ]; do
 	    DO_AEX=""
 	    ;;
 	-c) shift
+	    if test -n "$FSTESTCFG" ; then
+		echo "The '-c' option (or 'smoke') can only be specified once. "
+		echo "If you want to run tests in multiple configurations," \
+			"use -c CFG1,CFG2,..."
+		exit 1
+	    fi
 	    for i in ${1//,/ }
 	    do
 		validate_config_name "$i"
@@ -317,6 +323,11 @@ while [ "$1" != "" ]; do
 	    fi
 	    ;;
 	smoke)
+	    if test -n "$FSTESTCFG" ; then
+		echo "You can use either '-c' or 'smoke', not both! " \
+			"'smoke' means '-c 4k -g quick'."
+		exit 1
+	    fi
 	    FSTESTCFG=4k
 	    FSTESTSET="$FSTESTSET,-g,quick"
 	    ;;
@@ -357,6 +368,10 @@ while [ "$1" != "" ]; do
     shift
 done
 
+if test -z "$FSTESTCFG" ; then
+    FSTESTCFG=all
+fi
+
 if test -z "$FSTESTSET" -a -z "$ARG"
 then
     echo -e "No tests specified!\n"
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH] [xfstests-bld] Remove redundant gce-xfstests documentation

[Theodore Ts'o]

On Fri, Sep 23, 2016 at 01:56:10PM -0700, Eric Biggers wrote:
> README.GCE is no longer necessary because the same information, with
> more details, can now be found in gce-xfstests.md.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>

I had left this behind deliberately, because there are some old emails
and documentation aronud that pointed users at URL's like this:

https://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/kvm-xfstests/README.GCE

What I'll do instead is replace these files with pointers to the *.md
versions of the file in the Documentation directory.  A year or so
from now I'll get rid of the forwarding pointers, but I want to keep
these around for a bit.

Cheers,

						- Ted

Re: [PATCH] [xfstests-bld] Fix typos in xfstests-bld documentation

[Theodore Ts'o]

On Fri, Sep 23, 2016 at 01:56:11PM -0700, Eric Biggers wrote:
> Signed-off-by: Eric Biggers <ebiggers@google.com>

Applied, thanks.

					- Ted

Re: [PATCH] [xfstests-bld] kvm-xfstests: forbid conflicting specifications of FSTESTCFG

[Theodore Ts'o]

On Fri, Sep 23, 2016 at 01:56:12PM -0700, Eric Biggers wrote:
> It was possible to run kvm-xfstests with arguments like '-c encrypt
> smoke', in which case FSTESTCFG ended up set to "4k" because 'smoke'
> implies '-c 4k' and the second config specification overrode the first.
> If the user tries something like this, fail with a helpful error message
> rather than proceeding with a configuration that likely wasn't intended.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>

Applie,d thanks.

					- Ted

Re: [PATCH] [xfstests-bld] kvm-xfstests: forbid conflicting specifications of FSTESTCFG

[Eric Biggers]

On Fri, Sep 30, 2016 at 06:21:58PM -0400, Theodore Ts'o wrote:
> On Fri, Sep 23, 2016 at 01:56:12PM -0700, Eric Biggers wrote:
> > It was possible to run kvm-xfstests with arguments like '-c encrypt
> > smoke', in which case FSTESTCFG ended up set to "4k" because 'smoke'
> > implies '-c 4k' and the second config specification overrode the first.
> > If the user tries something like this, fail with a helpful error message
> > rather than proceeding with a configuration that likely wasn't intended.
> > 
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> 
> Applie,d thanks.
> 
> 					- Ted

Hi Ted,

Are you planning to push out new commits to the public xfstests-bld repository?

Thanks,

Eric

Re: [PATCH] [xfstests-bld] kvm-xfstests: forbid conflicting specifications of FSTESTCFG

[Theodore Ts'o]

On Fri, Oct 21, 2016 at 01:55:18PM -0700, Eric Biggers wrote:
> 
> Are you planning to push out new commits to the public xfstests-bld repository?

Done, pushed out.

						- Ted