Re: [LTP] [PATCH 4/7 ver2 w/attachment] Changes to pounder's build scripts (Cyril Hrubis)

Re: [LTP] [PATCH 4/7 ver2 w/attachment] Changes to pounder's build scripts (Cyril Hrubis)

[James Takahashi]

On Thu, 25 Aug 2011 12:14:03, Cyril Hrubis <chrubis@suse.cz> wrote:
> To: Lucy Liang <lgliang@linux.vnet.ibm.com>

Hi Cyril,

Lucy was a summer intern here at IBM, but her internship has ended.  I'll
try to resolve any open issues with her pounder patch submission.  Please
direct any future comments to me.

> > diff --git a/tools/pounder21/build_scripts/ltp b/tools/pounder21/build_scripts/ltp
> > index 68dcdbe..70defe4 100755
> > --- a/tools/pounder21/build_scripts/ltp
> > +++ b/tools/pounder21/build_scripts/ltp
> > @@ -55,23 +55,24 @@ fi
> >  
> >  # NAK the setregid EPERM -> EINVAL patch, because it's
> >  # broken on 2.6!  May be fixed some time after 20050804 release.
> > -if [ ! -e "testcases/kernel/syscalls/setregid/setregid02.c.pounder" ]; then
> > -	echo "Patching some holes in ltp..."
> > -	cp -pRdu testcases/kernel/syscalls/setregid/setregid02.c testcases/kernel/syscalls/setregid/setregid02.c.pounder
> > -	patch -p1 < $POUNDER_SRCDIR/ltp-setregid-fix.patch
> > -	RESULT=$?
> > -	if [ $RESULT -ne 0 ]; then
> > -		echo Patching failed.
> > -		exit 1
> > -	fi
> > -fi
> > +#if [ ! -e "testcases/kernel/syscalls/setregid/setregid02.c.pounder" ]; then
> > +#	echo "Patching some holes in ltp..."
> > +#	cp -pRdu testcases/kernel/syscalls/setregid/setregid02.c testcases/kernel/syscalls/setregid/setregid02.c.pounder
> > +#	patch -p1 < $POUNDER_SRCDIR/ltp-setregid-fix.patch
> > +#	RESULT=$?
> > +#	if [ $RESULT -ne 0 ]; then
> > +#		echo Patching failed.
> > +#		exit 1
> > +#	fi
> > +#fi
> 
> Patching LTP before build from this build script is not really long term
> solution. We should get these patches applied to LTP (as it should have
> been done long time ago) and drop this logic entrirely.

I agree that this smells like a workaround, not a long term solution.

I'll investigate whether the setregid02 patch is still needed or not,
then I'll resubmit this patch.

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH 4/7 ver2 w/attachment] Changes to pounder's build scripts (Cyril Hrubis)

[Cyril Hrubis]

Hi!
> Lucy was a summer intern here at IBM, but her internship has ended.  I'll
> try to resolve any open issues with her pounder patch submission.  Please
> direct any future comments to me.

Okay.

> > Patching LTP before build from this build script is not really long term
> > solution. We should get these patches applied to LTP (as it should have
> > been done long time ago) and drop this logic entrirely.
> 
> I agree that this smells like a workaround, not a long term solution.
> 
> I'll investigate whether the setregid02 patch is still needed or not,
> then I'll resubmit this patch.

Ideally if these patches are needed, they should be merged into LTP and
dropped from here. (I've found at least two LTP patches there).

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH 6/7 ver2 w/attachment] Modified pounder install and run scripts

[Cyril Hrubis]

Hi!
> > I'm not happy to have tarballs stored in the git for several reasons. Is
> > this really needed? Shouldn't having directories with files serve the
> > same purpose?
> 
> The tarball form makes more sense since we want to select and extract
> only one of the available schedules.

Hmm, but wouldn't copying directory, or even better symlinking it do the
same job?

> These schedule tarballs already exist in the git repository.  Lucy's
> patch merely moved them all into their own subdirectory to improve the
> file organization.  In fact, she even removed one, so now there are
> only 3 instead of 4 :-)

Well, that is exactly the the problem with tarballs, you can't say this
for sure unless you checks by hand.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH 6/7 ver2 w/attachment] Modified pounder install and run scripts

[Cyril Hrubis]

Hi!
Any update on this? I could probably live with the tarbals, but we
should at least do something about the LTP patches.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH 6/7 ver2 w/attachment] Modified pounder install and run scripts

[Cyril Hrubis]

Hi!
> > Any update on this? I could probably live with the tarbals...
> 
> I'm happy to hear you're feeling flexible about this one.  I started
> fiddling with turning those into subdirs, but found there was being some
> ripple effect into another script which was turning this into a bigger
> job than I currently have time for.  I was going to counter-propose that
> we just leave things as-is for now -- i.e., leave the existing tarballs
> where they currently exist -- but I'd be quite pleased if you'd accept
> moving them to their new home since the new organization makes it
> easier to understand how to use pounder.

I would still rather see this as dirs, but if the change is more than
just untar them and change one script, I could live with the tarballs
for now.

> >  but we
> > should at least do something about the LTP patches.
>  
> I just perused this issue more closely, and realize that the diff is
> already doing what you want.  The existing script patches the setregid02
> subtest, but Lucy's patch comments out those lines.
> 
> I could delete them completely rather than commenting them out, but
> I'd appreciate keeping the comments for now in case I encounter the
> original problem with some older distro. 

Well there are two patches, one that is used to add some include lines
in case of debian distro and actually that one is still in place and
even may be correct. Could you check if this one is correct, int this
case we would just apply it to LTP and drop it from pounder entirely.

PS: the second patch for setregid is not likely to apply now as there
    were some changes in the source code.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT 
space for its ease of implementation, lower cost, and increased 
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH 6/7 ver2 w/attachment] Modified pounder install and run scripts

[Cyril Hrubis]

Hi!
> > The main mission of Lucy's patch set is to enable pounder usage for
> > the world.  Being able to run LTP side by side with your own in-house
> > tests and applications is a handy framework, and I'm hoping that Lucy's
> > patch set will help to grow a community of happy pounder users.  If you
> > could defer this issue for now, it might enable others to contribute
> > towards fixing this problem (and perhaps the tarball issue as well).  
> > 
> Hi Cyril,
> 
> Any chance that you can accept these pounder patches?  Even though
> they don't fix everything you'd like, they definitely move pounder
> a quantum leap forward in enabling others to use pounder.

Thanks for the reminder, merged.

And looking forward to future patches for the rest of the issues ;).

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

[LTP] [PATCH 1/7 ver2 w/attachment] Updated pounder's documentation

[Lucy Liang]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]


Updated the README and SCHEDULER doc files. Merged QUICKSTART
with README. README gives an overview of building/running pounder
and how its files/subdirectories are organized. SCHEDULER goes
into detail about how to create, modify, build, and run tests and
test schedulers. Also added a new CONFIGURATION document that
explains pounder's environment variables. CONFIGURATION and
SCHEDULER are now located in a newly created doc/ directory.

Signed-off-by: Lucy Liang <lgliang@linux.vnet.ibm.com>
---
 tools/pounder21/CHANGELOG         |   59 ++++++
 tools/pounder21/QUICKSTART        |   20 --
 tools/pounder21/README            |  272 ++++++++++++++++++++---------
 tools/pounder21/SCHEDULER         |  150 ----------------
 tools/pounder21/doc/CONFIGURATION |  107 +++++++++++
 tools/pounder21/doc/SCHEDULER     |  352 +++++++++++++++++++++++++++++++++++++
 6 files changed, 711 insertions(+), 249 deletions(-)
 delete mode 100644 tools/pounder21/QUICKSTART
 delete mode 100644 tools/pounder21/SCHEDULER
 create mode 100644 tools/pounder21/doc/CONFIGURATION
 create mode 100644 tools/pounder21/doc/SCHEDULER


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Updated-pounder-s-documentation.patch --]
[-- Type: text/x-patch; name="0001-Updated-pounder-s-documentation.patch", Size: 44131 bytes --]

diff --git a/tools/pounder21/CHANGELOG b/tools/pounder21/CHANGELOG
index c248d96..4543f3a 100644
--- a/tools/pounder21/CHANGELOG
+++ b/tools/pounder21/CHANGELOG
@@ -1,5 +1,64 @@
 This is a log of changes to pounder21.
 
+pounder30-2011-08-09
+- Created new documentation CONFIGURATION and moved it and SCHEDULER
+  into a newly created doc/ directory
+- Deleted the test-all test scheduler
+- Created /schedulers directory and moved the remaining test schedulers there
+- Removed option to specify "NONE" when asked to unpack test scheduler during build
+- Removed check for existing kernel directory in /tmp in test_scripts/build_kernel
+  since it appears that some files get lost after running build_kernel once; Instead
+  just untar the kernel each time we run the test script to be on the safe side
+- ltp test script would pass even if it didn't build currently, fixed this in
+  test_scripts/ltp
+- changed ltp build_script to install ltp to $POUNDER_TMPDIR
+- removed QUICKSTART and included it in README instead
+- removed trailing "/" from POUNDER_LOGLOCAL export in libpounder.sh
+- Added functionality for automatic skipping of subtests (see README)
+- Created xterm_stress build script and merged 00xbonkers with it
+- Created ide_cdrom_copy build script and merged 00check_cdrom_presence with it
+- Merged nasm and schedutils build scripts with the lame build script
+- Merged time_test build script with the time_consistency and time_drift build
+  scripts
+- Created test_repo/ directory
+- Uncommented a piece of code in time_drift that allowed it to always pass
+- Added pounder -c option for creating new test schedulers
+- Modified POUNDER_VERSION in libpounder.sh
+
+pounder30-2011-07-21
+- Updated bonnie++, ipmitool, kernel (used in build_kernel), and memtest script to latest versions
+- Updated memtest build scripts and $POUNDER_HOME/src/memtest.patch
+- Added functionality for skipping of subtests
+  - Added functionality for automating the skipping of subtests (see README)
+- Removed unnecessary 00checklatest test
+- Moved checking for system requirements from test run to build phase
+  - Affects bonnie++, memtest, cpufreq, and ide_cdrom_copy
+- Added environment variable MAX_FAILURES that, if defined, sets
+  an upper bound on the number of failures a looped test will allow
+  before aborting the test altogether (see SCHEDULER)
+- Added functionality for removing and re-adding subtests to the test scheduler (see SCHEDULER)
+- Updated README, SCHEDULER, and config files
+
+pounder21-2011-04-08:
+- LTP: Updated to LTP 20101031 release.
+- Build kernel testcase - Updated kernel from 2.6.18 to 2.6.38.
+- Updated 2.6.38 kernel source tar in pounder cache.
+- Did corresponding kernel changes i.e for 2.6.38 in "memtest" testcase too.
+- Files modified are:-
+  -$POUNDER_HOME/test_scripts/memtest.
+  -$POUNDER_HOME/test_scripts/build_kernel .
+  -$POUNDER_HOME/build_scripts/memtest.
+  -$POUNDER_HOME/build_scripts/build_kernel.
+  -$POUNDER_HOME/opt/memtest.sh. [Actually this file need to get changed in tux1 cache].
+
+pounder21-2011-04-12
+-Integrated bash-memory testcase in pounder21
+-Files added/modified are:-
+ -Copied bash-memory test case tar to pounder cache.
+ -Added file $POUNDER_HOME/build_scripts/bash-memory
+ -Added file $POUNDER_HOME/test_scripts/bash_memory
+ -Added file $POUNDER_HOME/tests/T10single/T03bashmemory
+
 pounder21-2006-11-07:
 - Fix a bug in randasys on x86-64 where we had insufficient random bits and
   would truncate whatever we got, leading to all 0 arguments by simply
diff --git a/tools/pounder21/QUICKSTART b/tools/pounder21/QUICKSTART
deleted file mode 100644
index d2a0ef4..0000000
--- a/tools/pounder21/QUICKSTART
+++ /dev/null
@@ -1,20 +0,0 @@
-Quick and Dirty Guide to Setting Up Pounder
-Copyright (C) 2003-2006 IBM.
-
-0. Install system.  gcc and related development packages are required by
-   pounder; for extra stress testing, enable X too.
-1. Download and unpack the LTP tarball.  You've already done this.
-2. cd testcases/pounder21/.  You've already done this too.
-3. Set up a NFS server to export "/pounder".
-4. Add the following to "config":
-
-export DO_X_TESTS=1
-export NFS_SERVER=<your NFS server here>
-export NTP_SERVER=pool.ntp.org
-
-5. ./Install
-6. ./pounder
-
-This should take approximately two days to run to completion.  If your machine
-hangs, you can use the magic SysRq key (if you built it into the kernel) to
-obtain debugging information, kdumps, etc.
diff --git a/tools/pounder21/README b/tools/pounder21/README
index fd5a252..6621a14 100644
--- a/tools/pounder21/README
+++ b/tools/pounder21/README
@@ -1,46 +1,211 @@
-This is pounder21, as of 2006-01-24.  Copyright (C) 2003-2006 IBM.
-The above line is used to detect the pounder release version.  If
-you change the line, be sure to update build_scripts/00checklatest.
+This is pounder30 as of 2011-08-09.  Copyright (C) 2003-2011 IBM.
+(Do not delete top line. It is used for version checking.)
+
+It would be a good idea to read this README file and the SCHEDULER and
+CONFIGURATION files (in the doc/ directory) prior to dabbling with pounder!
 
 Licensing
 =========
 All files in this tarball are licensed under the GPL.  Please see
 the file COPYING for more details.
 
-Overview
+Contents
 ========
-This package is a system stress test.
-
-Unlike the original pounder, pounder21 *does* report pass/fail and
-it is NOT infinite.  There is a -k option to kill the tests manually,
-though ^C in the pounder terminal works.  With the new scheduler,
-one can enforce an order in which tests are run, and even control
-which ones get run in parallel.  See SCHEDULER for details.
-
-There are only two prerequisites:
-
-    - Get a CD with some data on it and put in the drive.
-      This is used to test optical drives, which are typically
-      the only IDE devices on a server.
-    - Make sure you can mount an NFS server.  See libpounder.sh for
-      config details.
+1. Overview
+2. Getting Started
+3. Files and Directories
+4. The Install Script
+5. Configuration
+6. The Pounder Script
+7. Credits
 
-If you downloaded the source tarball, then do this to get started:
+Overview
+========
+Pounder provides a framework for building, running, and logging results
+for user-defined sets of tests.  Almost any test or test suite may be run
+as a subtest from within this framework, including the LTP test suite.
+(For more guidelines on building, scheduling, and running user-defined
+subtests, see doc/SCHEDULER)
+
+Getting Started
+===============
+
+Some sample test "schedules" comprised of various publically available
+tests, including LTP, are provided. The default test schedule illustrates
+how one might use pounder and is also a useful general purpose stress test.
+
+The following steps describe how to build and run the default schedule:
+
+	0. Install your operating system.  gcc and related development packages are
+		required to build pounder.  Missing dependencies will be identified at
+		build time. X development packages are needed for the included video test.
+
+	1. Download and unpack the LTP tarball.  You've already done this.
+
+	2. cd tools/pounder21/.  You've already done this too.
+
+	3. (optional) Set up a NFS server to export "/pounder21" (unless you wish 
+		to skip nfs tests).
+
+	4. (optional) Modify any variables in "config" (see doc/CONFIGURATION for details).
+
+	5. Run "make install" to build tests for your machine
+		The Install script will attempt to build all the subtests in the
+		build_scripts folder. It will prompt you for the test scheduler
+		you want to unpack. Go ahead of type "default" or simply press
+		enter. It will then ask if you want to automate skipping of
+		failed subtests. If you enter "y", the script will automatically
+		delete any subtests from the test scheduler that fail to build.
+		If you enter "n", the script will prompt you each time a test
+		fails to build on whether or not to skip the failed test.
+       
+	6. Run "./pounder" to start the tests (run "./pounder -h" for usage options).
+
+	7. Press ^C or run "./pounder -k" to stop the tests
+		The default scheduler runs tests for 48 hours, but you can set a new
+		duration in seconds by modifying config (see doc/CONFIGURATION for details)
+		or by using the -d option when starting pounder (./pounder -d <duration in seconds>)
+
+	8. Run "make mrclean" to restore everything to the state before the tarball 
+		was unpacked (running this command will of course require you to 
+		rebuild with "make install" for the next pounder run)
+
+See doc/SCHEDULER for details on defining the order in which tests are run, and whether they
+are run serially or in parallel.
+
+A few of the sample subtests have prerequisites:
+
+	- ide_cdrom_copy: Requires a CD with some data on it to be put in the drive.
+
+	- nfs, ping_nfs: Make sure you can mount an NFS server. Specify NFS in config
+		or run "./pounder -n ipaddr"
+
+	- xterm_stress: Make sure you can start X sessions. Enable X testing by setting
+		the DO_X_TESTS flag in config or run "./pounder -x"
+
+These tests can be skipped during the build phase if reqs aren't met though.
+
+Files and Directories
+=====================
+Below are brief descriptions of the files and directories found under the pounder/
+directory.
+
+Files:
+
+	CHANGELOG
+		- A log of changes made to pounder
+	COPYING
+		- GNU general public license info
+	Install
+		- The script used to build pounder
+	Makefile
+		- Makefile for pounder
+	debug.c
+		- Debugging routines used for logging pounder results
+	infinite_loop.c, timed_loop.c, fancy_timed_loop.c
+		- Procedures used to run tests repeatedly (see doc/SCHEDULER for more
+		information)
+	config
+		- Environment variables used for customizing pounder run are defined
+		here (see doc/CONFIGURATION for details)
+	libpounder.sh
+		- More environment variables defined here. Unlike the ones in config,
+		these are not meant to be modified by the user. (see doc/CONFIGURATION
+		for details)
+	nfs_logging
+		- Script that sets up user-defined NFS server for logging pounder output.
+		This script is executed when pounder is run with $NFS_LOGGING enabled in
+		config (see doc/CONFIGURATION) or when "pounder -r" is used. Normally when
+		running pounder, test output will be directly logged to $POUNDER_LOGLOCAL,
+		but with NFS logging enabled, output will instead be logged to user-specified
+		remote directory of an NFS server, $NFS_LOGSERVER:$NFS_LOGDIR.
+		See doc/CONFIGURATION for more information on these variables.
+	pounder
+		- Script used to run pounder. (see "The Pounder Script" section below
+		for details)
+	proclist.c
+		- Manages list of processes during pounder run.
+	README
+		- This file, which gives an overview of pounder's structure and how to
+		build and start pounder.
+	run.c
+		- Program to run the tests in the test scheduler.
+
+Directories:
+
+	build_scripts/
+		- Scripts to build your subtests go here. (see doc/SCHEDULER for details)
+	doc/
+		- Contains the SCHEDULER file, which describes how to create, build,
+		schedule, and run your own tests with pounder.
+		- Contains the CONFIGURATION file, which describes pounder's environment
+		variables.
+	schedulers/
+		- Test scheduler tarballs are in here. (see doc/SCHEDULER for details)
+	src/
+		- Sources packaged with pounder are in here.
+	test_repo/
+		- This directory is a copy of the default test scheduler. It provides an
+		example of what an test scheduler should look like after unpacking.
+	test_scripts/
+		- Scripts to run your subtests go here. (see doc/SCHEDULER for details)
+	tests/
+		- Symlinks to run the tests in a particular order. (see doc/SCHEDULER for
+		details)
+
+After running "make install," you will see three additional directories:
+
+	opt/
+		- Third party packages (LTP, kernel, etc) go here.
+	tmp/
+		- Temporary directory to hold files that a test needs.
+	log/
+		- Logs of output from pounder runs go here.
+
+Note that for the provided tests, third party test packages (bonnie, kernel, etc) aren't
+packaged with pounder. The build scripts should download them to opt/ (stored in
+$POUNDER_OPTDIR) and build them as necessary. The use of a cache might come in handy here
+(see doc/CONFIGURATION for details regarding the $POUNDER_CACHE variable).
 
-    1. Run "./Install" - this builds tests for your machine
-       Proceed to step 2.
+The Install Script
+==================
+The Install script has no options.  Run it to build whatever tests have been
+imported into the pounder package.
 
-If you downloaded a binary tarball, then do this to start testing:
+Configuration
+=============
+See doc/CONFIGURATION documentation file for details.
 
-    2. Run "./pounder" (see pounder script for usage options) to 
-        start the tests
+The Pounder Script
+==================
+The pounder script has the following syntax:
 
-    3. When you want to stop the tests press ^C or run "./pounder -k"
+Usage: ./pounder [-g logdir] [-x] [-d duration] [-n ipaddr] [-m max_failures] [-f] [-h|-u|-r|-k|-l|-e subtests|-i subtests|-c scheduler] [-s]
+
+-h              Brings up this menu
+-c scheduler    Creates a new test scheduler called scheduler-tests.tar.gz in the pounder/schedulers folder.
+                All subtests to be packaged with this scheduler must first be placed in the pounder/tests folder.
+-x              Enable X stress tests.
+-d duration     Run pounder for duration seconds.
+-n ipaddr       Use ipaddr for NFS tests.
+-f              Remove pounder pid file before running.
+-u              Unmount NFS log storage.
+-r              Remount NFS log storage.
+-g logdir       Use logdir as the log directory. (You probably want -s too.)
+-s              Store logs locally.
+-l              List (both included and excluded) subtests that came with the test scheduler
+-e subtests     Exclude subtests from next pounder run
+-i subtests     Include previously excluded subtests in the next pounder run
+-k              Kill pounder.
+
+run "./pounder" to run all subtests
+run "./pounder subtest" to run just one particular subtest
+        (example: ./pounder tests/T90ramp/D02build_kernel)
 
 Credits
 =======
 o Inspired by Sammy Benjamin (sammy@us.ibm.com).  None of his code remains
-  in pounder21 today.
+  in this version of pounder today.
 o Modifications and additions by members of the LTC xSeries Kernel Team:
     Darrick Wong (djwong@us.ibm.com)
     Chris McDermott (lcm@us.ibm.com)
@@ -56,6 +221,7 @@ o Modifications and additions by members of the LTC xSeries Kernel Team:
     Pradeep Kumar (pradeepkumars@in.ibm.com)
     Bhaskar Rangaswamy (bharanga@in.ibm.com)
     Manikandan Chidambaram (cmanikandan@in.ibm.com)
+    Lucy Liang (lgliang@us.ibm.com)
 o Other contributers:
 
 Also utilizes:
@@ -71,55 +237,3 @@ o schedutils, to test CPU affinity (with lame)
 
 (note that the above packages are not distributed with pounder
  and are simply installed by the installer script)
-
-Improvements in pounder2
-========================
-This iteration of pounder you're looking at has been reworked a bit.
-First, pounder environment variables are defined in libpounder.sh.
-There are a lot more of them than there used to be.
-
-Second, I've attempted to make test integration a bit easier than it
-used to be.  There are several new directories; they are detailed below.
-
-build_scripts/   Put a script to build your test in here.
-config/          Put config files for your test in here.
-src/             Sources packaged with pounder go in here.
-opt/             Third party packages (LTP, kernel, etc) go here.
-tmp/             Temporary directory for files that a test needs.
-test_scripts/    Put a script to run your test in here.
-tests/           Symlinks to run the tests in a particular order.
-                 See the SCHEDULER documentation file for details.
-log/             Logs from pounder runs go here.
-
-Like before, all the tests are run in parallel.
-
-Note that third party test packages (LTP, kernel, etc) aren't packaged
-with pounder; the build scripts should download them and build them
-as necessary.
-
-The Install Script
-==================
-The Install script has no options.  Run it to build whatever tests have been
-imported into the pounder package.
-
-Configuration
-=============
-See the Configuration section of the SCHEDULER documentation file for details.
-See libpounder.sh for the actual configuration variables.
-
-The pounder Script
-==================
-The pounder script has the following syntax:
-
-Usage: ./pounder [-l logdir] [-x] [-d duration] [-n ipaddr] [-f] [-u|-r|-k] [-s]
-
--x      Enable X stress tests.
--d      Run pounder for duration seconds.
--n      Use ipaddr for NFS tests.
--f      Remove pounder pid file before running.
--u      Unmount NFS log storage.
--r      Remount NFS log storage.
--l      Use logdir as the log directory. (You probably want -s too.)
--s      Store logs locally.
--k      Kill pounder.
-
diff --git a/tools/pounder21/SCHEDULER b/tools/pounder21/SCHEDULER
deleted file mode 100644
index 92ace7b..0000000
--- a/tools/pounder21/SCHEDULER
+++ /dev/null
@@ -1,150 +0,0 @@
-This document describes the operation and configuration of the test scheduling
-framework in the pounder2 package.  This document reflects pounder21 as of
-2004-12-20, though the scheduler isn't likely to change much.
-
-Author: Darrick Wong <djwong@us.ibm.com>
-Copyright (C) 2004 IBM.
-
-Overview
-========
-The scheduler in the original pounder release was too simplistic--it would kick
-off every test at once, simultaneously.  There was no attempt to ramp up the
-machine's stress levels test by test, or to run only certain combinations, or
-even run the tests one by one before beginning the real load testing.
-
-In addition, the test scripts had a very simple pass/fail mechanism--failure
-was defined by a kernel panic/oops/bug, and passing was defined by the lack of
-that condition.  There was no attempt to find soft failures--situations where
-a test program would fail, but without bringing the machine down.  The test
-suite would not alert the user that these failures had occurred.
-
-Consequently, Darrick Wong rewrote the test scheduling framework to achieve
-several goals--first, to separate the test automation code from the tests
-themselves, to allow for more intelligent scheduling of tests, to give better
-summary reports of what passed (and what didn't), and finally to improve the
-load testing that this suite could do.
-
-Configuration File
-==================
-The test suite's configuration file is $POUNDER_HOME/libpounder.sh.  That file
-defines several variables that are referenced throughout the rest of this 
-document.  Obviously, these variables should be customized for your particular
-machine's set up.
-
-Files
-=====
-Each test has to provide at a bare minimum, two files:
-
-build_scripts/<testname> and test_scripts/<testname>.
-
-Temporary files should go in $POUNDER_TMPDIR; source and binaries should go
-in $POUNDER_OPTDIR.
-
-Build Scripts
-=============
-As the name implies, the script in build_scripts is in charge of downloading
-and building whatever bits of code are necessary to make the test run.  The
-variable $POUNDER_CACHE defines a web-accessible directory containing cached
-tarballs of whatever it is you're trying to build.
-
-Should there be a failure in the build script that is essential to the ability
-to run a test, the build script should return 0 to halt the main build process
-immediately.
-
-Also, be aware that distributing pre-built binary tarballs is not always a good
-idea because distros are not always good at ABI/library path compatibility,
-despite the efforts of LSB, FHS, etc.  These will go away in the (very) long
-term, however.
-
-Anatomy of a Test Script
-========================
-The requirements on test scripts are pretty light.  First, the building of the
-test ought to go in the build script unless it's absolutely necessary to build
-a test component at run time.
-
-Second, the script must catch SIGTERM and clean up after itself.  SIGTERM is
-used by the test scheduler to stop tests.
-
-The third requirement is much more stringent: Return codes.  The script should
-return 0 to indicate success, 1-254 to indicate failure (the common use is to
-signify the number of failures), and -1 or 255 to indicate that the there was
-a failure that cannot be fixed.
-
-Note: If a test is being run in a timed or infinite loop, returning -1 or 255
-has the effect of cancelling all subsequent loops.
-
-Quick map of return codes to what gets reported:
-0             = "PASS"
--1            = "ABORT"
-255           = "ABORT"
-anything else = "FAIL"
-
-Also note: If a test is killed by an unhandled signal, the test is reported as
-failing.
-
-Scheduling Tests
-================
-The current test scheduler borrows a System V rc script-like structure for
-specifying how and when tests should be run.  Everything under the tests/
-directory is used for scheduling purposes; files under that tree should have
-names that follow the following standard:
-
-   [type][sequence number][name]
-
-"type" is the type of test.  Currently, there are two types, 'D' and 'T'.  'T'
-signifies a test, which means that the scheduler starts the test, waits for the
-test to complete, and reports on its exit status.  'D' signifies a daemon
-"test", which is to say that the scheduler will start the test, let it run in
-the background, and kill it when it's done running all the tests in that
-directory.
-
-The "sequence number" dictates the order in which the test are run.  00 goes
-first, 99 goes last.  Tests with the same number are started simultaneously,
-regardless of the type.
-
-"name" is just a convenient mnemonic to distinguish between tests.
-
-File system objects under the tests/ directory can be nearly anything--
-directories, symbolic links, or files.  The test scheduler will not run
-anything that doesn't have the execute bit set.  If a FS object is a
-directory, then the contents of the directory are executed sequentially.
-
-Running Tests Repeatedly
-========================
-Two helper programs are provided to run tests repeatedly:
-
-    timed_loop duration command [arguments]
-
-This program will run "command" repeated until the number of seconds given
-as "duration" has passed.
-
-    infinite_loop command [arguments]
-
-This program runs "command" repeatedly until sent SIGTERM.
-
-Examples
-========
-
-Let's examine the following test scheduler hierarchy:
-
-tests/
-    D00stats
-    T01foo
-    T01bar
-    T02dir/
-        T00gav -> ../../test_scripts/gav
-        T01hic -> ../../test_scripts/hic
-    T03lat
-
-Let's see how the tests are run.  The test scheduler will start off by scanning
-the tests/ directory.  First it spawns D00stats and lets it run in the
-background.  Next, T01foo and T01bar are launched at the same time; the
-scheduler will wait for both of them to complete before proceeding.  Since T01foo
-is a file and not just a symbolic link, there is a fair chance that T01foo runs
-some test in a loop for a certain amount of time.  In any case, the scheduler
-next sees T02dir and proceeds into it.
-
-In the T02dir/, we find two test scripts.  First T00gav runs, followed by
-T01hic.  Now there are no more tests to run in T02dir/, so the scheduler heads
-back up to the parent directory.  T03lat is forked and allowed to run to
-completion, after which D00stats is killed, and the test suite exits.
diff --git a/tools/pounder21/doc/CONFIGURATION b/tools/pounder21/doc/CONFIGURATION
new file mode 100644
index 0000000..8557ea9
--- /dev/null
+++ b/tools/pounder21/doc/CONFIGURATION
@@ -0,0 +1,107 @@
+This document describes the environment variables found in the pounder30 package
+as of 2011-8-09.
+
+Author:
+Lucy Liang <lgliang@us.ibm.com>
+	
+Copyright (C) 2011 IBM.
+
+Contents
+========
+1. The libpounder.sh File
+2. The config File
+
+The libpounder.sh File
+======================
+The "libpounder.sh" file defines most of the environment variables used in the test
+suite and referenced throughout the documentation. These variables are not
+intended to be modified by the user, although they can be if customization is desired.
+Below is a brief description of these variables (see libpounder.sh for details):
+
+	DATE			- the current date, used for logging
+	DEFAULT_SCHEDPACK	- name of the default test scheduler, "default"
+	TESTS			- list of scripts from the test_scripts/ directory
+	BUILDS			- list of scripts from the build_scripts/ directory
+	POUNDER_HOME		- the pounder/ directory
+	POUNDER_PIDFILE		- pid file created when running pounder
+	POUNDER_LOGLOCAL	- the log/ directory where output of ALL pounder runs
+				get logged
+	POUNDER_LOGDIR		- the log/$DATE directory where output of only the
+				current pounder run get logged
+	POUNDER_TMPDIR		- the tmp/ directory used for storing temporary files
+				used for test runs
+	POUNDER_OPTDIR		- the opt/ directory used for storing third party packages
+				used by subtests, which can be fetched from web or from
+				a user-created cache (see $POUNDER_CACHE below)
+	POUNDER_SRCDIR		- the src/ directory containing source files packaged with
+				pounder
+	POUNDER_VERSION		- the pounder version
+	NR_CPUS			- the number of cpus on the system
+
+The config File
+===============
+The "config" file defines a few environment variables that ARE intended to be modified
+by the user for customizing pounder runs. The variables are described below:
+
+	DURATION		- Time in seconds for pounder to run. Setting this variable
+				to 0 will not put an upper bound on pounder run time.
+
+	MAX_FAILURES		- Maximum number of test failures allowed for each subtest
+				using infinite_loop or timed_loop (see the "Running Tests Repeatedly"
+				section in SCHEDULER for more info on these two procedures) before aborting.
+				Setting this variable to 0 will not put an upper bound on any
+				subtest failures.
+
+
+	NFS_LOGGING             - Enables/disables NFS logging. Setting this variable to
+				1 will enable NFS logging of pounder output; pounder will
+                             	log output to remote directory on NFS server specified
+                                by $NFS_LOGDIR and  $NFS_LOGSERVER (see below), which
+                                will be mounted on $POUNDER_LOGLOCAL (see libpounder.sh).
+                                Setting this variable to 0 will disable this feature; all
+				output for pounder runs will be stored locally directly in
+				$POUNDER_LOGLOCAL instead.
+
+	NFS_LOGSERVER           - IP address of the NFS server to use for logging pounder results.
+				NFS_LOGGING should be enabled to use this feature.
+
+	NFS_LOGDIR		- Path to the log directory on $NFS_LOGSERVER; If $NFS_LOGGING
+				is enabled, pounder will attempt to mount $NFS_LOGSERVER:$NFS_LOGDIR/
+				on $POUNDER_LOGLOCAL (see libpounder.sh).
+
+	POUNDER_CACHE  		- Address of the cache to use for fetching outside packages,
+                        	The cache is a user-created web-accessible directory
+                        	containing cached tarballs/scripts/etc. used for
+                        	the various tests you intend to build. This is optional
+                        	but useful for saving download time and keeping everything in one place.
+
+				For instance, the build_kernel subtest requires downloading a
+				linux kernel tarball during build time (see build_scripts/build_kernel).
+				Instead of calling "wget http://www.kernel.org/pub/linux/kernel/v2.6/$TARNAME"
+				to retrieve the tarball, we can pre-download and store it in a user-created online
+				directory, then call "wget ${POUNDER_CACHE}${TARNAME}," where POUNDER_CACHE
+				is the address of the directory. Other provided subtests: bonnie++, lame, ipmitool,
+				and memtest also make use of this cache.
+
+				Examples of some things you may want to include in your cache for building
+				the provided tests:
+					bonnie++-1.03e.tgz	(for the bonnie++ subtest)
+					linux-2.6.39.tar.gz	(for the build_kernel subtest)
+					ipmitool-1.8.9.tar.gz	(for the ipmitool subtest)
+					...
+
+				These can be found in $POUNDER_OPTDIR after you run "make install" on the
+				default package.
+
+	[These variables below are used by specific subtests contained in the provided default
+	test scheduler, but they can be incorporated into other user-defined subtests as well.]
+
+	DO_X_TESTS		- 0 disables X system testing, 1 enables X system testing.
+				Used by the xterm_stress subtest.
+
+
+	NFS_SERVER=0		- IP address of the NFS server to use for nfs and ping_nfs
+				subtests. Setting this variable to 0 disables nfs testing.
+
+	NTP_SERVER		The NTP server to use. By default, it's set to pool.ntp.org.
+				Used by the time_drift subtest.
diff --git a/tools/pounder21/doc/SCHEDULER b/tools/pounder21/doc/SCHEDULER
new file mode 100644
index 0000000..2df082a
--- /dev/null
+++ b/tools/pounder21/doc/SCHEDULER
@@ -0,0 +1,352 @@
+This document describes the operation of the test scheduling framework in
+the pounder30 package.  This document reflects pounder30 as of 2011-8-09.
+
+Authors:
+Darrick Wong <djwong@us.ibm.com>
+Lucy Liang <lgliang@us.ibm.com>
+	
+Copyright (C) 2011 IBM.
+
+Contents
+========
+1. Overview
+2. Test Files
+3. Build Scripts
+4. Test Scripts
+5. Scheduling Tests
+6. Running Tests Repeatedly
+7. The Provided Test Schedulers
+8. Creating Your Own Test Scheduler
+9. Including and Excluding Tests
+
+Overview
+========
+The scheduler in the original pounder release was too simplistic--it would kick
+off every test at once, simultaneously.  There was no attempt to ramp up the
+machine's stress levels test by test, or to run only certain combinations, or
+even run the tests one by one before beginning the real load testing.
+
+In addition, the test scripts had a very simple pass/fail mechanism--failure
+was defined by a kernel panic/oops/bug, and passing was defined by the lack of
+that condition.  There was no attempt to find soft failures--situations where
+a test program would fail, but without bringing the machine down.  The test
+suite would not alert the user that these failures had occurred.
+
+Consequently, Darrick Wong rewrote the test scheduling framework to achieve
+several goals--first, to separate the test automation code from the tests
+themselves, to allow for more intelligent scheduling of tests, to give better
+summary reports of what passed (and what didn't), and finally to improve the
+load testing that this suite could do.
+
+Test Files
+==========
+Each test should only need to provide three files:
+
+1) build_scripts/<testname>
+	- The build_scripts/ directory contains scripts that take care of checking for
+	system requirements, downloading the relevant packages and binaries, and building
+	any code necessary to run the subtests. See the "Build Scripts" section below for
+	more information.
+
+2) test_scripts/<testname>
+	- The test_script/ directory contains scripts that take care of running the actual tests.
+	See the "Test Scripts" section below for more information.
+
+3) tests/.../[T|D]XX<testname>
+	- The tests/ directory represents our unpackaged "test scheduler" (if your tests/
+	directory is empty, that means you haven't unpacked any test schedulers yet and will
+	need run "make install" to unpack a scheduler - see "The Provided Test Schedulers"
+	section for more information. The test_repo/ directory also provides an example of what
+	an unpacked test scheduler should look like). The files in the tests/ directory are
+	usually symlinks that point to files in test_scripts/. The order in which the subtests are
+	run upon starting pounder depends on how the files in tests/ are named and organized.
+	See the "Scheduling Tests" section below for more information.
+
+Note: <testname> should be the same in the build_scripts/, test_scripts/, and tests/ folders.
+(Example: build_scripts/subtest1, test_scripts/subtest1, and tests/D99subtest1 would be valid.
+build_scripts/subtest1, test_scripts/subtest1_different, and tests/D99subtest1 would not.)
+See "Scheduling Tests" below for a detailed description of naming rules for files in the tests/
+directory.
+
+Build Scripts
+=============
+As the name implies, a script in build_scripts/ is in charge of downloading
+and building whatever bits of code are necessary to make the test run.
+
+Temporary files needed to run a test should go in $POUNDER_TMPDIR. Third party source,
+packages, binaries should go in $POUNDER_OPTDIR. Third party packages can be fetched
+from the web or from a user-created cache, a web-accessible directory containing
+cached tarballs and files used for whatever it is you'll need to build.
+(see "$POUNDER_CACHE" in doc/CONFIGURATION for more information)
+
+Should there be a failure in the build script that is essential to the ability
+to run a test, the build script should exit with error to halt the main build 
+process immediately.
+
+Also, be aware that distributing pre-built binary tarballs is not always a good
+idea. Though one could cache pre-built binary tarballs rather than source, it may 
+not be a good idea because distros are not always good at ABI/library path compatibility,
+despite the efforts of LSB, FHS, etc.  It is always safest to build your
+subtests from source on your target system.
+
+The build_scripts/ directory provides some examples.
+
+Test Scripts
+============
+A script in test_scripts/ is in charge of running the actual test.
+
+The requirements on test scripts are pretty light.  First, the building of the
+test ought to go in the build script unless it's absolutely necessary to build
+a test component at run time. Any checking for system requirements should also
+go in the build script.
+
+Second, the script must catch SIGTERM and clean up after itself.  SIGTERM is
+used by the test scheduler to stop tests.
+
+The third requirement is much more stringent: Return codes.  The script should
+return 0 to indicate success, 1-254 to indicate failure (the common use is to
+signify the number of failures), and -1 or 255 to indicate that the there was
+a failure that cannot be fixed.
+
+Note: If a test is being run in a timed or infinite loop (see the
+"Running Tests Repeatedly" section below for details), returning -1 or 255
+has the effect of cancelling all subsequent loops.
+
+Quick map of return codes to what gets reported:
+0             = "PASS"
+-1            = "ABORT"
+255           = "ABORT"
+anything else = "FAIL"
+
+Also note: If a test is killed by an unhandled signal, the test is reported as
+failing.
+
+Put any temporary files created during test run in $POUNDER_TMPDIR.
+
+The test_scripts/ directory provides some examples.
+
+Scheduling Tests
+================
+Everything under the tests/ directory is used for scheduling purposes. The current
+test scheduler borrows a System V rc script-like structure for specifying how and
+when tests should be run. Files under tests/ should have names that follow the this
+standard:
+
+   [type][sequence number][name]
+
+"type" is the type of test. Currently, there are two types, 'D' and 'T'.  'T'
+signifies a test, which means that the scheduler starts the test, waits for the
+test to complete, and reports on its exit status.  'D' signifies a daemon
+"test", which is to say that the scheduler will start the test, let it run in
+the background, and kill it when it's done running all the tests in that
+directory.
+
+The "sequence number" dictates the order in which the test are run. 00 goes
+first, 99 goes last.  Tests with the same number are started simultaneously,
+regardless of the type.
+
+"name" is just a convenient mnemonic to distinguish between tests. However,
+it should be the same as the corresponding name using in build_scripts and
+test_scripts. (A test with build script "build_scripts/subtest" and
+test script "test_scripts/subtest" should be defined as  something like
+"tests/T00subtest" as opposed to "tests/T00whatever_i_feel_like")
+
+Test names must be unique!
+
+File system objects under the tests/ directory can be nearly anything--
+directories, symbolic links, or files.  The test scheduler will not run
+anything that doesn't have the execute bit set.  If a FS object is a
+directory, then the contents of the directory are executed sequentially.
+
+Example:
+
+Let's examine the following test scheduler hierarchy:
+
+tests/
+    D00stats
+    T01foo
+    T01bar
+    T02dir/
+        T00gav -> ../../test_scripts/gav
+        T01hic -> ../../test_scripts/hic
+    T03lat
+
+Let's see how the tests are run.  The test scheduler will start off by scanning
+the tests/ directory.  First it spawns D00stats and lets it run in the
+background.  Next, T01foo and T01bar are launched at the same time; the
+scheduler will wait for both of them to complete before proceeding.  Since T01foo
+is a file and not just a symbolic link, there is a fair chance that T01foo runs
+some test in a loop for a certain amount of time.  In any case, the scheduler
+next sees T02dir and proceeds into it.
+
+In the T02dir/, we find two test scripts.  First T00gav runs, followed by
+T01hic.  Now there are no more tests to run in T02dir/, so the scheduler heads
+back up to the parent directory.  T03lat is forked and allowed to run to
+completion, after which D00stats is killed, and the test suite exits.
+
+Running Tests Repeatedly
+========================
+Two helper programs are provided to run tests repeatedly, timed_loop and infinite_loop.
+(This version of pounder currently also includes a fancy_timed_loop.c file, but it's only
+meant to be used for the random_syscall and will most likely be merged with timed_loop.c
+in the future, so we will ignore it here for now.)
+
+1. timed_loop
+
+    timed_loop [-m max_failures] duration_in_seconds command [arguments]
+
+This program will run "command" with the given arguments repeated
+until the number of seconds given as "duration" has passed or the
+command has failed a total of "max_failures" times, whichever comes first.
+If the $MAX_FAILURES variable is set (defined in config, see CONFIGURATION
+for details), then the program will run until command has failed a total of
+$MAX_FAILURES time (as long as it's not overridden by the -m option).
+
+2. infinite_loop
+
+    infinite_loop [-m max_failures] command [arguments]
+
+This program runs "command" repeatedly until sent SIGTERM or the
+command has failed a total of "max_failures" times. If the $MAX_FAILURES
+variable is set (defined in config, see CONFIGURATION for details), then
+the program will run until command has failed a total of $MAX_FAILURES time
+(as long as it's not overridden by the -m option).
+
+Examples:
+
+1. test_repo/T90ramp/D02build_kernel contains the following line:
+
+	"$POUNDER_HOME/infinite_loop $POUNDER_HOME/test_scripts/build_kernel"
+
+	which will run the build_kernel test script repeatedly until sent SIGTERM
+	or until it has failed a total of $MAX_FAILURES times.
+
+	"$POUNDER_HOME/infinite_loop -m 10 $POUNDER_HOME/test_scripts/build_kernel"
+
+	would run the build_kernel test script repeatedly until sent SIGTERM or
+	until it has failed 10 times, regardless of what $MAX_FAILURES is.
+
+2. test_scripts/time_drift contains the following line:
+       
+	"$POUNDER_HOME/timed_loop 900 "$POUNDER_SRCDIR/time_tests/drift-test.py" $NTP_SERVER $FREQ"
+
+	which will run the drift-test.py script ($NTP_SERVER and $FREQ are some args passed to drift-test.py)
+	for 15 minutes or until it has failed a total of $MAX_FAILURES times.
+
+	"$POUNDER_HOME/timed_loop -m 10 900 "$POUNDER_SRCDIR/time_tests/drift-test.py" $NTP_SERVER $FREQ"
+
+	would run the drift-test.py script for 15 minutes or until it has failed 10 times, regardless of
+	what $MAX_FAILURES is.
+
+The Provided Test Schedulers
+============================
+This version of pounder provides 3 test schedulers: the "default," "fast," and "test" test schedulers.
+The tarred versions can be found in the schedulers/ directory as default-tests.tar.gz, fast-tests.tar.gz,
+and test-tests.tar.gz respectively.
+
+To unpack a test scheduler, run "make install" in the pounder/ directory and enter the name of the
+scheduler you would like to unpack at the first prompt.
+
+Example of unpacking the "fast" test scheduler:
+
+	# make install
+	./Install
+	Looking for tools...make g++ lex gcc python wget sudo diff patch egrep rm echo test which cp mkdir .
+	All tools were found.
+	WHICH TEST SCHEDULER SETUP DO YOU WANT TO UNPACK?
+	[Choose from:
+	default-tests.tar.gz
+	fast-tests.tar.gz
+	test-tests.tar.gz]
+	[Or simply press ENTER for the default scheduler]
+	Scheduler selection: fast
+
+Descriptions of the provided test schedulers:
+
+1. default - provides a general purpose stress test, runs for 48 hours unless the -d option
+		is used when starting pounder.
+2. fast - basically the same as default, except it runs for 12 hours by default.
+3. test - provides a set of useless tests. Each test simply passes, fails, aborts, or sleeps for
+		some period of time. They don't do anything useful but can be used to see how
+		the test scheduling setup works.
+
+Creating Your Own Test Schedulers
+=================================
+From the pounder directory, place the desired tests in the tests/ directory according to
+the rules described in the "Scheduling Tests" section above. Then run the following command:
+
+./pounder -c name_of_scheduler
+
+to create a new test scheduler, which will be tarred as name_of_scheduler-tests.tar.gz and
+placed in the schedulers/ directory.
+
+Example Usage:
+
+	# ls ./schedulers
+	default-tests.tar.gz  fast-tests.tar.gz     test-tests.tar.gz
+
+	# ls ./tests
+	T00hwinfo
+
+	# ./pounder -c new_sched
+
+	# ls ./schedulers
+	default-tests.tar.gz  fast-tests.tar.gz     new_sched-tests.tar.gz      test-tests.tar.gz
+
+	After unpacking the "new_sched" test scheduler during install, the tests/ directory should
+	contain the T00hwinfo subtest along with a tests/excluded/ directory (see the "Including and
+	Excluding Tests" section below for details regarding the tests/excluded directory).
+
+Including and Excluding Tests
+=============================
+After unpacking the test scheduler and building each individual test, running
+"./pounder" will automatically run every test included in the tests folder. If you
+would like to run only ONE test, run "./pounder ./tests/<some subtest>". If you would
+like to run a portion of tests, you can use the "./pounder -e" option to exclude
+certain subtests from subsequent pounder runs:
+
+Example:
+
+Suppose you have already ran "make install" and unpacked the default test scheduler.
+The tests/ directory should now contain the subtests to be run
+
+1) ./pounder -l
+	- lists all of the subtests that came with the currently active test scheduler.
+	The output should look something like:
+
+	------------------	
+	#./pounder -l
+	Included subtests:
+	...
+	.../ltp-full-xxxxxxxx/tools/pounder/tests/T10single/T00xterm_stress
+	.../ltp-full-xxxxxxxx/tools/pounder/tests/T00hwinfo
+	...
+
+	Excluded subtests:
+	[NONE]
+	------------------
+
+2) ./pounder -e "tests/T10single/T00xterm_stress tests/T00hwinfo"
+	- will exclude T00xterm_stress and T00hwinfo from any subsequent pounder runs.
+	This command essentially moves the two tests from the "tests" folder to the
+	"tests/excluded" folder for temporary storage, where they will remain until
+	re-included back into the test scheduler (this is also why all test names
+	should be unique). A file "tests/excluded/testlist" keeps track of which tests
+	have been excluded from the test scheduler and what their original paths were.
+
+3) ./pounder -l
+	- should now output something like:
+
+	------------------
+	#./pounder -l
+	Included subtests:
+	...
+
+	Excluded subtests:
+	T00xterm_stress
+	T00hwinfo
+	------------------
+
+4) ./pounder -i "T00xterm_stress T00hwinfo" - will re-include these subtests back into
+	the test scheduler. They will be moved from the tests/excluded folder back into
+	the tests folder under their original paths.

[-- Attachment #3: Type: text/plain, Size: 351 bytes --]

------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

[LTP] [PATCH 6/7 ver2 w/attachment] Modified pounder install and run scripts

[Lucy Liang]

[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]


Made changes to two files here, the Install script that builds
pounder, and the pounder script that runs it. Updated the Install
script to have it now list the available test schedulers for user
selectrion prior to starting the build process. Install also now
includes the functionality for allowing users to skip subtests
that failed to build rather than just exiting out of the entire
build process due to a single subtest failure.

The updated pounder script now includes the -m, -c, -l, -e, -i,
and -h options (README has more info). The -c, -e, -i options
handle creation and modification of test schedulers. The -m
option sets an upper bound on output of repeatedly run subtests.
The -l option lists subtests packaged with the test scheduler
and the -h option gives description of pounder usage. Also moved
all the provided test schedulers into newly created schedulers/
directory.

Signed-off-by: Lucy Liang <lgliang@linux.vnet.ibm.com>
---
 tools/pounder21/Install                         |   63 ++++++--
 tools/pounder21/default-tests.tar.gz            |  Bin 1441 -> 0 bytes
 tools/pounder21/fast-tests.tar.gz               |  Bin 1292 -> 0 bytes
 tools/pounder21/pounder                         |  174 ++++++++++++++++++-----
 tools/pounder21/schedulers/default-tests.tar.gz |  Bin 0 -> 1663 bytes
 tools/pounder21/schedulers/fast-tests.tar.gz    |  Bin 0 -> 1494 bytes
 tools/pounder21/schedulers/test-tests.tar.gz    |  Bin 0 -> 1057 bytes
 tools/pounder21/test-tests.tar.gz               |  Bin 1006 -> 0 bytes
 tools/pounder21/testall-tests.tar.gz            |  Bin 314 -> 0 bytes
 9 files changed, 186 insertions(+), 51 deletions(-)
 delete mode 100644 tools/pounder21/default-tests.tar.gz
 delete mode 100644 tools/pounder21/fast-tests.tar.gz
 create mode 100644 tools/pounder21/schedulers/default-tests.tar.gz
 create mode 100644 tools/pounder21/schedulers/fast-tests.tar.gz
 create mode 100644 tools/pounder21/schedulers/test-tests.tar.gz
 delete mode 100644 tools/pounder21/test-tests.tar.gz
 delete mode 100644 tools/pounder21/testall-tests.tar.gz


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0006-Modified-pounder-install-and-run-scripts.patch --]
[-- Type: text/x-patch; name="0006-Modified-pounder-install-and-run-scripts.patch", Size: 23014 bytes --]

diff --git a/tools/pounder21/Install b/tools/pounder21/Install
index fe8db05..5bbfe2f 100755
--- a/tools/pounder21/Install
+++ b/tools/pounder21/Install
@@ -24,7 +24,7 @@ source libpounder.sh
 export USE_CACHE=1
 
 # do we actually _have_ a cache server?
-if [ -z "$POUNDER_CACHE" ]; then
+if [ -z "$POUNDER_CACHE" -o "$POUNDER_CACHE" == "0" ]; then
 	export USE_CACHE=0
 fi
 
@@ -73,7 +73,12 @@ UNPACKED=0
 
 while [ "$UNPACKED" -lt 1 ]; do
 	# Unpack default test configuration?
-	echo -en "Which test scheduler setup do you want to unpack? [$DEFAULT_SCHEDPACK or \"NONE\"] "
+	SCHEDULERS=`ls $POUNDER_HOME/schedulers | awk -F"-tests.tar.gz" '{print $1}'`
+	echo "WHICH TEST SCHEDULER SETUP DO YOU WANT TO UNPACK?"
+	echo "[Choose from:"
+	echo "$SCHEDULERS"
+	echo "[Or simply press ENTER for the default scheduler]"
+	echo -n "Scheduler selection: "
 	read f
 	if [ -z "$f" ]; then
 		SCHEDPACK="$DEFAULT_SCHEDPACK"
@@ -81,22 +86,26 @@ while [ "$UNPACKED" -lt 1 ]; do
 		SCHEDPACK="$f"
 	fi
 
-	if [ "$f" != "NONE" ]; then
-		rm -rf tests/*
+	rm -rf tests/*
 
-		tar -xzvf "$SCHEDPACK-tests.tar.gz"
+	tar -xzvf "$POUNDER_HOME/schedulers/$SCHEDPACK-tests.tar.gz"
 
-		if [ "$?" -ne 0 ]; then
-			echo "Unable to untar $SCHEDPACK-tests.tar.gz; please try again."
-		else
-			echo "Untarred $SCHEDPACK-tests.tar.gz successfully."
-			UNPACKED=1
-		fi
+	if [ "$?" -ne 0 ]; then
+		echo "Unable to untar $SCHEDPACK-tests.tar.gz; please try again."
 	else
+		echo "Untarred $SCHEDPACK-tests.tar.gz successfully."
 		UNPACKED=1
 	fi
 done
 
+echo -en "Would you like to automate skipping of failed subtests? (subtests that failed to build will automatically be removed from test scheduler) [y/n]? "
+read f
+if [ "$f" == "y" -o "$f" == "Y" ]; then
+	AUTO_SKIP=1
+else
+	AUTO_SKIP=0
+fi
+
 # start builds...
 for i in $BUILDS
 do
@@ -104,10 +113,34 @@ do
 		continue
 	fi
 	if [ -x "build_scripts/$i" ]; then
-		echo "Building $i..."
-		"build_scripts/$i" $*
-		if [ "$?" -ne 0 ]; then
-			exit 1
+		FOUND=`find $POUNDER_HOME/tests -name *$i`
+		if [ -n "$FOUND" ]; then	
+			"build_scripts/$i" $*
+			BUILD_ERR=$?
+			if [ "$BUILD_ERR" -ne 0 ]; then
+				if [ $AUTO_SKIP -eq 0 ]; then
+					echo -en "$i build failed with Error $BUILD_ERR. If this is a subtest, would you like to skip it [y/n]? "
+					read f
+					if [ "$f" == "y" -o "$f" == "Y" ]; then
+                        			rm `find $POUNDER_HOME/tests -name *$i` > /dev/null 2>&1
+						if [ "$?" -ne 0 ]; then
+							echo "Failed to remove $i from test scheduler. $i is either not a subtest included in $SCHEDPACK-tests.tar.gz or is incorrectly defined in $POUNDER_HOME/tests (See SCHEDULER for naming rules if this is the case)."
+							echo -en "Skip anyway? [y/n] "
+							read f
+							if [ "$?" == "y" -o "$f" == "Y" ]; then
+								exit 0
+							elif [ "$f" == "n" -o "$f" == "N" -o -z "$f" ]; then
+								exit 1
+							fi
+						fi
+                			elif [ "$f" == "n" -o "$f" == "N" -o -z "$f" ]; then
+						echo "Exiting install ..."
+						exit 1
+					fi
+				else
+					rm `find ./tests -name *$i` > /dev/null 2>&1
+				fi
+			fi
 		fi
 	fi
 done
diff --git a/tools/pounder21/default-tests.tar.gz b/tools/pounder21/default-tests.tar.gz
deleted file mode 100644
index 7f1bb20b7fafc15682ed07273211243e2a6b4442..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 1441
zcmZXRdo+}J9EZnci>8xtv}?AO(I8t1lah|M$t~@gQY1<YqoXSk($wk|Vyek(sU{(n
zgGiz_a_glm2Q}7xqK4x(BiD>^d3k@|_5XhUeExf$596j5<-_<2XNtyH`o8dP8(KnS
z$4h^+l=^k8^q#`~mA2NEe-9tOW1V=%C}o@T7L#pB5Uu83#A&lI)rookeV4xJ;o9BP
z;}#dLnzrQ@pRo+`v)9tCFXcPC3%NQUt#}+J=dF`<JWI^GABwlGk(T&&nAD#oXM;UM
zGEkJq1b(2*4=kx|$IH8t4brmNSq@uX*tHTKH7o@qwg`FcE%-)eAM81n)I35mh`{wp
zM0h`NcrV!JcU;f8I7s00gS-^6eq(;+{vl;S{kMU1;!%|LC9(f5Y@svfCFU2sn1;}>
zNTkm%t#7RGICao7a?6z_x_ei_!-|fX2&<=jNR=TQz(HK)AtZsy9E#-H8D!2zZ7}O&
zyTns}=cH9RERQ|X(qvlsX-YC2QCo2yN>p5@r#S5~re#jDM9$a>BC$#WioCpu7Ur4a
zjbm%FjtN;Q5S9!9xxq1t?Lu_O0qJYH&G$$JMmoZuy5aMs==63~dLwK9b65s-dmj>R
zq3VdC&PJFOb8<mZq{P;^qC_L0Ui}e@6jSMcbnbf>Hv7a)j?L{tdZ(x5cZ~(GZc-0K
zdo*2lf03$ifhn?HLWR>@^M}zXU;X6Qk{dApjmVfZ+_PFw$Qo|Kb~Kx+)c|Fu0F?8o
z1Il+C8_(p363<tX@h-m4ubyV!cU<F*65vnid`42~U|Cnzm~VN*jraBR)_Ded2$QA(
z)gb^ZwXRIzMY{H@=$12xab#S{OP4*%J`_>`t0AY3!~$lZly(4qs1^ZxD{~S(D4GRt
za}^_ju++RjikQtAj^IKYRb|M}+$-p~C6RqxSCGt-)B}s9!mI976H6IJV5yXbK;I5E
z?(M^`tnI@nwZy`FmDwzI-F6(@TV_E|3fk{aLX>ngtFU?DQsD@GlEAcUfF>PbCplpk
zk@3ozdC{UQH%MIUo7vUTOqY+s!#FOfp-uJ#OnSg?Tba)guT}=S&c)$UqS<;FMiubD
zJsAQUs==|h4sPjQ?ZGuiRXqb(aLU)WLbX<8`3CgD)daiWPJqJ!NUZjPI)5jc2CuFF
zGKb-s9E<bsgrYA%X@dA_34DLGvGG_XHW4ZuCKv__c)|jv8H*;2IQh^NLb3DKHKE)N
zd<o5I@LtKbFC1Z)d6aM6bmR13h_JPf-QGf7pF0e4=>SFpvOfovZ)XbNcAy-ZcY+Ry
z+ZQUqb*yaYghky08C(v9o4<^M6Aj{eH=|VCaav^94f;pRCf2r3W|gxfxlnY(ECRXo
zq8y`(N~jhXsXHb4!guuTzNcp~zdQH*V4wD1r$AhX7(5AFi&3#x8cqOzNpKnO9~s=t
z2E9i>jWvLSrD5$e{H6%fCFwgO1-S)r)R!JwtighvXj5FxVtD;DeC^^1`8+!)e->LQ
z$L%NE;B$K~SgPAWxzGgS<k$!Q3~&ku>Q2y)XAqVVio<yvvGZY>tzrLJ@{>j34p^8B
zsK}ptV5~Sd?J_s{`To7jR9h~_r1OtrIpLb*Eku9AFWr1se2(I577cQHY-~=;V?_`A
zyvzqP&`$G;kuTuL*kG||m72tCIpISjSI7o^Jxj|-Wjw)nZI3mWI7b7+F%-OLk`XZE
zPDK{#J)7oQ!3;LAxJ;nzXMZ4-Y*7s+Prf{ez!+S{e7pa2ectkc-sBA%GDU+Bl!TY1
z8!OlfEIL)3+R#XE`ZpsC36M{FR%c0W>-AVf#8tMaFma^B?aJ~;PuO)+EZ81yo;PL_
Zl~c2+lR^34=1S+5N2v@WDUT_X{{Sh`FIfNp

diff --git a/tools/pounder21/fast-tests.tar.gz b/tools/pounder21/fast-tests.tar.gz
deleted file mode 100644
index 37b58a22b1c10a74ef32cd2d9fd48dc62106f920..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 1292
zcmZvY`A?Gv9EV{d7Q}%Zsaj`&fgIW7iWVdI&I=+#P-=0;LDd3{AQCP+L3k01pe?q-
z+#p2CDI%%Pi)|_vR46DEok~Hj4lESQ-4^WIzVCPa1NQm(`6N#sDvxBgr8|3%*@~GP
z2T}$D?Jngk-JL(VT6?g{rTs4U@OQ`l*JsGQ*`vbb&2K|~dsve12D$qOZY8^l$MWLV
zf6CcnJ?(s0E3;vDRtKwcRXz#3T)1&zq-^)F%Gl*@&n~WOR6<D)slKFWU^ll#{0#>`
zn89m5t(nWAGf`N+IfB;P)DldusVm8p&aW#Q5LQ&`{y;x0fVJigV%dP9?&U2bk7A|k
zbkU#BVHByy;WQbWw-CE%sM+{*MCSDd_CmZXw%QVBDO8dByfFtA^&%bju{uVZVZ}NP
zKav$jBvD!XEI3Xy?B0Mk*6fX&Skr`*W;8qRv=ogMt3mBUZo2>MCnvn;<WB12nwY0@
zTjd|lbL7L_qqt5fLVOUo0fbV}OODTB^eL+}w@-a+pUUnNF6Itj7vJ-c7EO#Z&o2)e
z+3;s;yAFLeFyxqQP^I(t!{jPxc-ieRv9huaSauz-9AY7f+(ZNR<xl9(&cM6i0F4`8
ziDk5ybIQ5u$VpUt%-CD@f$1AzXW};#R6dFR!^gjLl5jVoLYVi3Y90#8`%jv9hKl=(
zQTn;EE5I#YV3I1mw#`COxHAZzA2N!14PolDZAU{$W4giC9tiIi(|WeeQ4N`g7_l8?
zGI;3%wL=|fdI3nC!wF8}-cIv(?J@8=niK!1D<$(t5;6iCfnBIWPsyRc@fOsW)CI+)
z5t08aMvbf^#_e@Xn;}e8SA$?kjY0-BL#p#FQ{hVqwA2=UY6KA(FbE#SD~}U`U1fTB
zUnDfI<57U&x-fbNT!=zx4@6DDxHTqijRCst#o6X_NXFy2;NsK>T(oeHIHCgH9@DYE
z$k))ouYlLL`?H2HO1T!zokw3y6V!$!qpcAMI$<2$u+~UyRZO5=T2x^SbsWNc$~CA8
z`1w2F9fK~fC+6G6*S*st+o!?m2_ZdTo~K7F9W=nBnJq_i-JDa0^hmi5(V`)3#UN_V
zN@8lZcVyt44B|&qSno?;s26>8qa#Ijc&Ste_19+q4da|trts4jk;F+WZ_j<eam?3)
ztjNyXUOEhG$KQ%G>C5qmDr=^8MchaDZ~{CYs3lRR6nk1VXlMx6SLl5P4|QmSH$YxR
zBTBJX@@AmjR7<Aq;PNoA!>R$XJ~1ZobLAS3T%Z8rZVzuwC<lDX^;8k8FQDTug613b
zqPVj-t+pi1tGyp;*L{|F2Bi|Bv3VG5>w#qBoO-N}ZL7#2Qsk(=%;_3;Py_jKoltA{
z*=W)|Xi;~y0^BuvG!Q5&X~YBZ$izOz)+Ce_lmdc#-Nrb7Nh;WifLwUofbRJAxrH$B
z4rmhRDMt3B82<5tac&g^SYME#Hs1#UL$L(6GP5}!rr`WlzZqB*g5NVWywKnEw7`hM
z8*5!G-2}$~*Y=_tB(O%u{B8+zNJ~$7`ozk=V?c+7oHd|Sr1H}Bq~K4q<-g^W0%D>q
z);@953q^~DC0(s0|B6(@F9Jq-P7Fr>3KI~KJpp}>W$FZmlTIx6lgW|N@ZfqhFPlq5
mgE9?H<4s_XH<m0Ku<RBo?G9r0zsr+%!R*oZ&&{gL%>Dyq*x#i9

diff --git a/tools/pounder21/pounder b/tools/pounder21/pounder
index 095e0c0..9382d87 100755
--- a/tools/pounder21/pounder
+++ b/tools/pounder21/pounder
@@ -19,29 +19,6 @@
 # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
 # 02111-1307, USA.
 
-# By default, pounder runs forever.  Howver, the -k option can be used to stop
-# all the tests.  Our process ID (which is the process-group ID of all our
-# children) is saved in a file called pounder_pgrp in the POUNDER_HOME
-# directory.  A negative sign is prepended to the PID so that a simple
-# "kill -TERM `cat $POUNDER_HOME/pounder_pgrp`" will stop all the tests.
-#
-# Howver, if a test starts an xterm, then all its sub-processes will run under
-# a new process-group, which requires that the test regester its own PID (with
-# a negative sign prepended) to the pounder_pgrp file.  See the testtime script
-# for an example of this.
-#
-# To schedule pounder to run for a limited length of time, use the -d option
-# to set a duration in hours for the run.  A process will be spawned that will
-# sleep the allotted time and then kill the process group(s) in pounder_pgrp.
-# If you decide to stop the tests, pounder -k will kill the sleeping process as
-# well.
-#
-# It should also be noted that in order to clean up completly, some tests may
-# need to trap interrupts and do some cleanup.  See the testnet script for an
-# example of this.
-#
-# Author: Darrick Wong <djwong@us.ibm.com> and John Stultz <johnstul@us.ibm.com>
-
 source libpounder.sh
 
 # This function kills off pounder and related subprocesses.
@@ -56,34 +33,158 @@ function dokill() {
 
 function help() {
 	cat << ENDL
-Usage: $0 [-l logdir] [-x] [-d duration] [-n ipaddr] [-f] [-u|-r|-k] [-s]
-
--x	Enable X stress tests.
--d	Run pounder for duration seconds.
--n	Use ipaddr for NFS tests.
--f	Remove pounder pid file before running.
--u	Unmount NFS log storage.
--r	Remount NFS log storage.
--l	Use logdir as the log directory. (You probably want -s too.)
--s	Store logs locally.
--k	Kill pounder.
+Usage: ./pounder [-g logdir] [-x] [-d duration] [-n ipaddr] [-m max_failures] [-f] [-h|-u|-r|-k|-l|-e subtests|-i subtests|-c scheduler] [-s]
+
+-h      	Brings up this menu
+-c scheduler	Creates a new test scheduler called scheduler-tests.tar.gz in the pounder/schedulers folder.
+		All subtests to be packaged with this scheduler must first be placed in the pounder/tests folder. 
+-x      	Enable X stress tests.
+-d duration	Run pounder for duration seconds.
+-n ipaddr	Use ipaddr for NFS tests.
+-f		Remove pounder pid file before running.
+-u      	Unmount NFS log storage.
+-r      	Remount NFS log storage.
+-g logdir      	Use logdir as the log directory. (You probably want -s too.)
+-s      	Store logs locally.
+-l      	List (both included and excluded) subtests that came with the test scheduler
+-e subtests     Exclude subtests from next pounder run
+-i subtests     Include previously excluded subtests in the next pounder run
+-k      	Kill pounder.
+
+run "./pounder" to run all subtests
+run "./pounder subtest" to run just one particular subtest
+        (example: ./pounder tests/T90ramp/D02build_kernel)
 ENDL
 }
 
+function exclude() {
+	echo "excluding from tests $@..."
+
+	POUNDER_TESTS=$POUNDER_HOME/tests
+	SUBTESTS_INC=`find $POUNDER_TESTS -name excluded -prune -o -type f -print -o -type l -print`
+
+	for i in $@
+	do
+		BASENAME=`basename "$i"`
+
+		ORIG_DIR=`pwd`
+		cd `dirname $i`
+		FULL_PATH=`pwd`/"$BASENAME"
+		cd $ORIG_DIR 
+
+		FOUND=`echo "$SUBTESTS_INC" | grep -x "$FULL_PATH"`
+
+		if [ -n "$FOUND" -a -x "$i" ]; then
+
+			ALREADY_EXCLUDED=`grep -w "$BASENAME" $POUNDER_TESTS/excluded/testlist | cut -d " " -f1`
+			if [ $ALREADY_EXCLUDED ]; then
+				echo $ALREADY_EXCLUDED
+				echo "$BASENAME has already been excluded from the test scheduler. Make sure the test names in the test scheduler are unique."
+				exit 1
+			fi
+
+			echo "$BASENAME" "$FULL_PATH" >> "$POUNDER_TESTS"/excluded/testlist
+			mv "$i" "$POUNDER_TESTS"/excluded/"$BASENAME"
+
+			if [ $? -eq 0 ]; then
+				echo "Successfully removed $i from test scheduler."
+			else
+				echo "Removal of $i from tests UNSUCCESSFUL."
+			fi
+		else
+			echo "$i is not a subtest included in the current scheduler. Use ./pounder -l for list of valid, excludable subtests."
+		fi
+	done
+}
+
+function include() {
+	echo "including in tests $@..."
+
+        POUNDER_EXCLUDED=$POUNDER_HOME/tests/excluded
+
+        for i in $@
+        do
+		ORIG_FILE=`grep -w "$i" $POUNDER_EXCLUDED/testlist | cut -d " " -f2`
+
+		if [ -n "$ORIG_FILE" ]; then
+			mv $POUNDER_EXCLUDED/$i $ORIG_FILE
+			if [ $? -eq 0 ]; then
+				sed "/$i /d" $POUNDER_EXCLUDED/testlist > $POUNDER_EXCLUDED/tempfile
+				mv $POUNDER_EXCLUDED/tempfile $POUNDER_EXCLUDED/testlist
+				echo "Successfully added $i back to test scheduler."
+			else
+				echo "Addition of $i to tests UNSUCCESSFUL."
+			fi
+		else
+			echo "$i is not an excluded subtest. It may already be included in the current scheduler. Use ./pounder -l for list of valid, includable subtests."
+		fi
+        done
+}
+
+function list_tests() {
+
+	if [ ! -d $POUNDER_HOME/tests ]; then
+		echo "Error: No test schedule found. Did you run make install?"
+		exit 1
+	fi
+
+	echo "Included subtests:"
+	INCLUDED_TESTS=`find $POUNDER_HOME/tests -name excluded -prune -o -type f -print -o -type l -print`
+	if [ -z "$INCLUDED_TESTS" ]; then
+		echo "[NONE]"
+	else
+		echo "$INCLUDED_TESTS"
+	fi
+	echo
+
+	echo "Excluded subtests:"
+
+	if [ ! -d $POUNDER_HOME/tests/excluded ]; then
+		echo "Error: $POUNDER_HOME/tests/excluded folder does not exist. Make sure your test scheduler was created or unpackaged correctly. Did you run make install?"
+		exit 1
+	fi
+
+	EXCLUDED_TESTS=`grep -v "#" $POUNDER_HOME/tests/excluded/testlist`
+	if [ -z "$EXCLUDED_TESTS" ]; then
+		echo "[NONE]"
+	else
+		echo "$EXCLUDED_TESTS" | cut -d " " -f1
+	fi
+
+}
+
+function create_scheduler() {
+	TESTS_EXCLUDED=$POUNDER_HOME/tests/excluded
+	REPO_EXCLUDED=$POUNDER_HOME/test_repo/excluded
+
+	if [ ! -d $TESTS_EXCLUDED ]; then
+		cp -r $REPO_EXCLUDED $TESTS_EXCLUDED
+	elif [ ! -e $TESTS_EXCLUDED/testlist ]; then
+		cp $REPO_EXCLUDED/testlist $TESTS_EXCLUDED/testlist
+	fi
+
+	tar -czf $POUNDER_HOME/schedulers/$@-tests.tar.gz tests
+}
 # process options: -x to run in xterms, -k to kill tests, -d to set duration,
 # -f to remove bogus pounder.pid files.
-while getopts d:kn:l:xurs? o
+while getopts d:kn:g:xure:i:m:c:shl? o
 do
 	case "$o" in
 	   d) export DURATION="$OPTARG";;
 	   k) dokill; exit;;
 	   n) export NFS_SERVER="$OPTARG";;
-	   l) export POUNDER_LOGDIR="$OPTARG";;
+	   g) export POUNDER_LOGDIR="$OPTARG";;
 	   x) export DO_X_TESTS=1;;
 	   f) rm -rf "$POUNDER_PIDFILE";;
 	   u) umount $POUNDER_HOME/log 2> /dev/null; exit 0;;
 	   s) export NFS_LOGGING=0;;
 	   r) ./nfs_logging; exit;;
+	   e) exclude $OPTARG; exit;;
+	   i) include $OPTARG; exit;;
+	   l) list_tests; exit;;
+	   m) export MAX_FAILURES="$OPTARG";;
+	   c) create_scheduler $OPTARG; exit;;
+	   h) help $0; exit;;
 	   '?') help $0; exit 1;;
 	esac
 done
@@ -157,6 +258,7 @@ fi
 # Dump environment variables...
 export > "$POUNDER_LOGDIR/environment"
 
+echo "Starting $POUNDER_VERSION"
 echo "STARTING TESTS." > /dev/tty
 echo "To kill all tests, run 'pounder -k' or press ^C."> /dev/tty
 
diff --git a/tools/pounder21/schedulers/default-tests.tar.gz b/tools/pounder21/schedulers/default-tests.tar.gz
new file mode 100644
index 0000000000000000000000000000000000000000..ac20bc9683618886e385a17e9fb2fe19b830e2fd
GIT binary patch
literal 1663
zcmV-_27vh=iwFQgJ~~bS1MQt#Z`(E$$NlV2!J!5A&?VtTB%7zbq(uv?&Cq2S_9Vy_
z9ShN|lDs6}ex&ToHk(FuL2*odeh+aHUr6}RbKwz5b*k;!v&pDnjH%?@JYp&KA2&=0
z5ri>{ss3F*OCmf$eB5rWS+!l#AmpQ|5b1jT)!jT_r79g~AnfXodwrkKKcW+?|DfEn
z{!LYNKH3WmOMmlcp0#ej2_vwGqOa=DB4O#zA{tE)cG`=taOC>GKvzqJ>Qz%$twPlT
zb<3<pi!4`2KXw(mQL08=GHX#)PG6wgWj0@;x>}W~YEZkH^#cecjY1ED2rZhb(4V99
z%gwW>S(T^guca#0Kl(kVXAkc_Q4b$*(p4v$x9d0QhF7ghe=(o&@CsBWg+fW0qB`l8
z=vs9sudc6Es$aiUjXIs`UoI}u$IC19;qv1B+rQD(yZ3*fx9@*@b2|OMzvXaQ+y52D
z%iFA6RHL-f+q;y5@n1wtFri;Z1dhlA(bLo3A;s;y$!gtAt$Mt?jh%KB;=j@V95+c(
zkCX>~YyPM8mslA8ujLnz|M_5F|Eu$J?W_~+<a6b&jb87k^w-Z3%m^ifP^t3+LWTGE
zf26$l>1>vjXS1YTnh5%7RiZ`JpzgLpX>#9A+uX!|BI#?4A&mZb?A!kZmh*bGXw+wy
zZS30rWBEVX<o_oA3ufX!BOLO7FYMSqnoheWsnO5sF6$8f84*5x`TOOcA1~f~ir-y+
zcyp!`udK{E73Wn|qy6Xh61B}Bn)aXc@>g&i!Lo1v=0|*+WbWtxPsV>Lw(*~t{Et#S
zU4Z!SfxY;@4)zQJ{qbPOf1af(o~KP!#Ph1YchbgS{5SdkL;S}k{zs7@5dVEJPW;~=
zM34rAi)H^r-gT-e;<js4+d67vDE<@9tojdQ9OAzh#<Bn1K?K$xGPeEGCMi?xx7+)6
zp5(ccHiqqg8~>$b#{LC^`kxoZvH$%+1Rfw<tolD;=5bX!ZR7Cke-V!O1krKI5&Imu
z{oDHUQ1q9ezYpyB|LZ~(=6^2R7>xhB^?yC_$AmKMd;Wi<j1&Jig9rkD@L2vI2NVAz
z@c%xr<G&0<e@;MuAK3awf#|PO0?^+BcKrvJ3s+^|{}|5y=(hf2)`=5605If#J{Twe
z(}M_dzh{B%|8Xe(pMwAQft~*clmB7R-v_q+lR)&380hZ<+x|r;`a}KK3%31-qCfb5
zKiKtuW)^J4dD2{~xNDS?T|k5LKfbO1bKbB2mqNh&&j%x||KA@(Fc%CKyZ*xpRm4f2
zS95o54BP+C{!h|h|KkkmKVBH^`rmpGf#nB|ZU0f;xlR5i2i1QirfgmRh4p`47{~tg
zAOg#O7TEbeovpGwjc-&_DmSZt4_f~(c+{`|r5x7(cwrp--yKBY2tvk=|Gdiz70;`(
z&Du_ta~C@RhwWc(<3Ho3{zD|p|GhAd{o8{Gd_bt!_Ah$r(k5HDE4mKbKiS%UWa@uZ
zn(IGc|Kl^F{r7_iEI(}Q>wo8=T>pXfA6~Hizq$V3mdTC7<KMoa{v)^R|N84cG&1M^
zg8v_%vG#wi2N8Jx(6Q@3QJOB3+R?!;8;0$F=lZW)pZ^5)A3uy^|C>Ps<{vzE{uj*p
zKgj>QVEcbEtI9G{uU<K9W7q%VN6-J<=6{^7&;Rtk{{znda#{c13?c{sp=101*Mazd
z*#GGVd;KpBM1R=-?FZZbgE{{N_Wydp)<2m2-*Enu7wr81yimp6LN$Emu8qO^&vyN<
zkZisF7sL6VUKnlt?|Kly1R!v1{~t{L2m3$0VEccOCxy#ve}+N-A8prv3fkZQlQXFQ
zdts#Y-+B;%>wgZc?f(K3Z3dn5lYiD6?*9eB?2-FF_I)(B{mja1SDia@```F~f?NHa
z=4zBXK;lF0|1He<Pgqj8|F;)x{dESI)kW4-m8;z!-w^*vG$EK{$|A{d)UW>(6ym=R
z2IBwpshhlP#t8)aXUv!OkDcEE=HU2G3GeIwI{w=!fb-5Bx&42sKXJYT`0)IXo7;ds
zs=xEjf&Tsd---T$l`7-1n&nA(<Ft*#?H^Mr9?Snn=p*Rg*MH78->rM~zsLS1<NWLT
zJMAOr-`hWK@7v~cT$LlV@g4qOQu&zvrjI9X`*`H~0{{R30000000000008jg@-MXS
Je}({{0038brBMI?

literal 0
HcmV?d00001

diff --git a/tools/pounder21/schedulers/fast-tests.tar.gz b/tools/pounder21/schedulers/fast-tests.tar.gz
new file mode 100644
index 0000000000000000000000000000000000000000..5984a5ce372367e33902adcc831d830ba7910dac
GIT binary patch
literal 1494
zcmZvZdpMH|9LML<X}N?J2dR04mQLj8Ns%q5#K~oqsE(Lio-R+Q$8BkP3s2O_s7|^u
zE#*=OT|~1YO)1QzqNtE%W@7Kgw)g#=&iVU%|N8v<`FzQ2BEhHKBZ#0UEA&qoT4O3q
zSC&TR&r#kx*OE=Cr1S0B;l+*1`xg4pGY*OJP5DkQ1C{+Q%RL_i+KbY>YmL?mHrfbH
z46e?08u^xVv#aFJj-k&i#W{&+&dtfmBkfsvd54!oE^wVy<xK9+sQ=W`cW**n;?vf;
zmD+8h{MDpAs_;xt?$Yso#s{^7CfFwM9;;bbs7#PHq`DUE+ppY7XFqW}=6LaBi!HMk
z|BX0TGuLSPMBBT0h7_*tAqA!A%X1lWD*pGASCjjD3OAqz=<b0VArVA-vc~$;JW(-q
zcT!o^?R^qzdx6!#vE;wcSR_kZKX0HMn3I-dcmJSt`*BWQ!p>@5O8A>D#+9<?f+@E;
zwvf(c3tiUArPDIuNcQkkX;2C6j-1JwTXBASamki#7Zg?v=3Y)?{bBj9RQq`5b>-TT
zDeLsdP2SvU7h3wvqE9TXVy=4f`@1_I6hLjqYeiuE;zN2w<-rxvMrj<LNK2kNL9*C_
zW$$W5Jgyn*ET6a(H_+B{F_crMc`rHn2VSsDxqx)kTHVoMNs9sss~K-`b^0*+wz51^
zPqP9eeRPbCKConxj|yrL(+Vvo#EO6l^ybSDH*R}OVVgaJm>6xOJpK|t8$b*lp`F`B
z8AY;A8F^Mg(8W5gv&GTm8o!1^9x{WF@i}Lsj2y%V4wr$y&B|+Ng*jZdi4K4mPYC|O
za5T7uSTE=j7%CN<+v27`Yene#VXx){voB(IK{(8gOpU2#hS1SFhP#=gAp`9CGU+di
zn^Lxx#TD-NV2Q6WY%eq0Z{Tk^Gt`%FR7k{Y*fB;9eyd}!kvfcQ-T*;NJ0SVtrI|%=
zwCD`;%EM$U7wNY<`L3I%1uU6BOD@A{LuNe?bngO~6cS$%5Rrn;%Z|7o`w^{_1U%3a
zqMa!i8KpK`rlw<~n`&-C`Z8TqbG8cUa}04BN>M!sbM)C8b2fU4W?0^h_}Tq*8J9rU
zX<OYHb}uXo@TyvLGuj5hT%J|{U3P!z{B=h#sdBXGJvRdjFYbiF0^Sb9ZQTo33|Vs*
zZm!PK%Jn^G5$UG98NM$Y-WO=;OLM@vYZ@6ojb)=qBqEh4O;|NF9Zll~Ieb1C%QBZR
zG2c{_9E>r(&*_5Xj6yZt!>s3cwXPQ)P5&zB1HB)E)HF;UhzXzK&Rr;deGSd{*}p_i
zi$WyO;QdbEuFRg1>+_+rC!@07uP@9@Rk^CxaDNgmRP};*FQnR+X03w66Sq*v4$@Eb
zP7rBmcNfN9U+BYM?f#-3PyNC5al(V0#RSQqPHz>&T_;|YuWP_FdG2A_z+5TBPXNz=
z@LwK=hZzMzir+y}O$U2*6DiK&^<CU69;3B7ft$hXpmB;qAm3z4WNq$*C!PLgF4Btj
z#)uvMBu|16CCjF04i&KRv$}fGxP*~vm!s3flhSMg3LehB+9OWh12Lt@nsMM*D&TtL
zHpnEMoWeE>aCg;++T<=A&R7C(QK;H7VKjitJk_*DHOE+m6zhD1R^x|CB>p;)Cy+}p
zu5DmliEGkO!O9`^U?bjG4wOv1nlvu?d5tY17fERez2J?F>U-fAe8NK>GgTd*ErmUZ
zy}_v&&J7sV_s5`;<gGio*b5h^?C}<y?k<rc<;#@W*kF7YDu079BB7d;q&ZdxizZ-L
zpO143c&uHgFS)!v=lU1OtKn9X1e(<}_g!Joc*O29ftkAm_~j4@r6k1++2YRwQ+?d1
zCs6kYPppR(Ul#TvYoB$i6TWXURWtNB02lnk^R~5y@G0lVIwY39LgdVH2Ra76hC=37
r^<W=D9V`l)?uC3U*)^B@NFa({e?+54_}@*cXMg#YHC{<5CJ_Ds-z7Vp

literal 0
HcmV?d00001

diff --git a/tools/pounder21/schedulers/test-tests.tar.gz b/tools/pounder21/schedulers/test-tests.tar.gz
new file mode 100644
index 0000000000000000000000000000000000000000..ddff53ee18b6c115b6cc0292f64a13abaccb048c
GIT binary patch
literal 1057
zcmV++1m61}iwFRrp*c<f1MOVjZ__Xk?sNZ&8|9I<wqrYhgm~!?lNd!%gm{{=#%&_H
zBuY})pO2j;Yz<vUt2k84eX5lHaN=t|pYOY~+gxRNHttykA%wX?m?L!sHAg}@FODU8
zlu9Zjqr$YKggK-K!me2xth3xp0sf(#N;CWBw2i#re@28KrnZK`zw$2~>Pr2bP|942
z{I`KE{%1rkyl~ZYABJGpbt}I2@=uA>{JSobJz%5JSU-%3SJ^xb6K$!nZ<Gbi8CUV2
z#&N#CT^IOw6EAE0TOQ0m)1Qmo{2Tj_|K?ERUz`m84)Wgyw)meA;;WlDqRsYE@V_Vi
z8_p@A(iPI>jvgnJNvZW8Y1WM0=y?1eoQ<!;Xq*LoH4kFg&=2OG<YBZN8T9+Vf^elE
zPuHsN$9(|(SkO1rJkxJPs{g;g1>#uL=l_$@e-Ffe)PK#Q&cAmZr+e?i5jZ0LI}ho<
z!oDU40P?Tzs=A%8*1q!XQ~>Vf|9ko8j?Vja;;-YsOWc<8f8^irZ(gp#tl1gB5G?Qb
z{)>Ny%NqY&=xLx`{nt_c2QUj1B<nPZGX?Pi@*vD$Vf3Cp<}v(GDuLX)&LEEZ1JF`%
z9zYVWBVVPEt*?s#1YWA38bq*2;~RY)rJI{iAzeo!_!g*0{nY1-#?{$FRb611$HVe;
zeUk22-);Yexkl9jBJW0l7x|EQc>qh5!zx}bm9N_eDpgvg4q!5ckJA}kPA3=dzQgSO
z#TR&Y@!@=g`t(6m@t@jA{7W3J|D>q&pWWoY*LnZ1_?IV9|7T>g{-fi7!1{k1*y4Xi
zURu-t`}miRssFf|d`F9cqW)v_Kh}TjqgMZUR^?Z(!JGd$gW_cvEzh3y)oqvq69R+j
zQ$o%EU!6+*pAoG8w}CDGtNK4{wvWf=|FZsX=6{|4kz)SmZRdZFw|kQOWBtF|sQEuF
z27uFS9|!oqL&Zk_anygUV3+?h^#9IaTmMmFP5<r7{}}z_|AH6(&(Z(e!9D*s`5i%5
z?iRNE-%<_u5dUY=)PI@I2GRf90Q!HoQIG%D_W$gy|K90;zRCYNL;r6D_4;qQzv?y2
z%sOzf@@n2vepLY;I*j8a@no>=|8@kxLGhm#{$H&Bq5s<l#{X`k@_%My;kU%W>pyxb
zaLA7RAB}JR?BV)P$v-z!|0<3X3w<21{^wBs!2Ta&Bkuog3>E*54dGwnaQ~N_(;fUb
zzWKk0{FnT@S-4yz%1R&i_<!{G-xdGT*}?zD#%4!A$MxTa{|O;kc$2Ku#6};FuKzJs
z{{Msd;ZL#upHTe$Un{uN|Ia^7zkZyYf4+J@y*wX>(ISk(TwR%X3)`R7e6kofoAd#m
bzr_Rsfj}S-2m}IwI9dD#?ssbA08jt`(w|Tl

literal 0
HcmV?d00001

diff --git a/tools/pounder21/test-tests.tar.gz b/tools/pounder21/test-tests.tar.gz
deleted file mode 100644
index fe3d576c115b61cefbda28552893c8af6f57e40e..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 1006
zcmV<K0}=cmiwFR#N8~{O1MQnjPuoBgg|p7D7-+Xm=FU^1s=5KGo0h7gYZQnfZi5rW
zM)c>`<FN_0XhI^7N%8p<$$1!N?BjE1?mV(6&C>B8D4cU)wRT6cn%t3-QpK@kK>1I^
zl{6|pkA$&uz;xJZdG6C}vSMs7{q?X&Za1A5t<nwur@D~p_@9s!`d@H8jaQ)_gO}>h
zjpRi6?<B3T(7y|6`d@IGTrE~v%VoIxVXb|c|7Ct&{#NGx7o*X*sLv>!wOpk&(0{G}
zDd*GZZjn&CWfb~v@IP_m^fy);s|x+Klr&(S+{B*i|L$mf6({3#HjJ)k3+Cl#?w(|E
zayxPihYz!O9<gk79}TCAA!GULhCY#dmw%B&!`HqFurJN{e=~{aZI`ig{1>FT^6@`^
zxhh_!*Q<D$*VNUo)#jk*{%`8PoTQtsaxeDL--_q;clCq*?a|O*9EAVLXjS^Zb-y=(
z{!jIn2jPD*rt1H<?)N6pztG<tSpF|L^8YTV=^w)UgYEfW-rjrtwU)w|Tz_SxK>pVS
zPx8M%amF}Oxqeae|3#Ppu#^84cmB7^!2ewU|M#1^{{xQyZ}Pv9kN)RUx$$42E&SgF
zjq%^(YQE)!O|E|*vEpN#+#VhK_#m`Kgm_ET{QtW1KhFQcT3*cm5ZeDv!2D0YY4~3h
z4}fg9j2-+hNh|MvwEvy(oc{&<-y0hJe{mq=|9<^Xpz(+rJ@<b@e;I84Z)5(qj{nN{
z|F~6%|6S0`|H}E+6Lv9+Q|6uy=Dv!iRR;J$3Wa$8W@!39Sp0wC_^+Gz&;3t=!~b1?
z@!x*q{U3If%?sOqV~o(67xTY)1_=Lm0own5<Ncq;cguNn8mNpN`u`5+e<3vd-vtf-
zmk$D4-6u&o{xeMHQM6>lxeoyB{b%_9&EWkXc9+$5|I23kFBS6tPQd(czp3(n5n|y-
zN#XyU#(%ZZZvRK{&7Xtb``_z-%K3b;SOzL%Tl^PPt^X!vg<JovxIq5b3G4X({`>jQ
zZ>MKJF29_AJsZc#O`OD8bm^W8c3d<L<x^614nH#AGt|dy;~&?5t0f%hQNA`+{8w(^
zH&6`NJ^ovgCXfGBov{Bu7+(LdyR5eM|EuwTLz+yH|K}eN|GNO=|NW+l|2B<pZ<bMz
zGIoytf=HJ8e`}k+eI45kR6X~9rGJo(|0R3me^S}9{STb}L4U7*kcB@bd+0BWTmKb&
z^Zx+)KlcB^b+otj|A@r8|3}6853Vu)(+U5||Fifmn)>{mp3UIP*o+Jw0000000000
c000000000000000003TxzaV#_LI8LG05)VdHvj+t

diff --git a/tools/pounder21/testall-tests.tar.gz b/tools/pounder21/testall-tests.tar.gz
deleted file mode 100644
index 5a60a6fda24621fdbb9e71584eda87c3ac9b7515..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 314
zcmb2|=HU2}v&V^vxg@o?BrzvP7ep89l_VB1yuIY;-)tbl{vqz=@(QJLx#R<hH$6SS
z7^KU5PU1<7E)2~PPx$!y^cC5dM_-ycpZ(vxM=kf(^*`~eXKnlFx_(CG1ec5JiiGOd
z$-5kA)_7>a*S_(A!jnWL4Wa!Bx3{?Zs)Y6HU$d#HeYgAXU-xfc`!nu;I&X19w`<ia
z&3e0O^%AY@Klvvc2pl=FzkIp+KPTz>K$Gm5v3{2d&*&^Ix1Ae5ce(k`qa~Am?Y?+o
zcIsO5yDLgUH785&UcvQQB{ehq(h}avNUPInMX5^{d+$=dep#>gr0wpxJ4@^rm96b5
znX}Y%ty#3`B)^qQi$6@N3tPQsQ`zO%>!r@_QXfmcPYblq{I)lgkpT^SxW9*KMs{r;
Ig9ZZw0Evi`YXATM


[-- Attachment #3: Type: text/plain, Size: 351 bytes --]

------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH 6/7 ver2 w/attachment] Modified pounder install and run scripts

[Cyril Hrubis]

Hi!
> Made changes to two files here, the Install script that builds
> pounder, and the pounder script that runs it. Updated the Install
> script to have it now list the available test schedulers for user
> selectrion prior to starting the build process. Install also now
> includes the functionality for allowing users to skip subtests
> that failed to build rather than just exiting out of the entire
> build process due to a single subtest failure.
> 
> The updated pounder script now includes the -m, -c, -l, -e, -i,
> and -h options (README has more info). The -c, -e, -i options
> handle creation and modification of test schedulers. The -m
> option sets an upper bound on output of repeatedly run subtests.
> The -l option lists subtests packaged with the test scheduler
> and the -h option gives description of pounder usage. Also moved
> all the provided test schedulers into newly created schedulers/
> directory.
> 
> Signed-off-by: Lucy Liang <lgliang@linux.vnet.ibm.com>
> ---
>  tools/pounder21/Install                         |   63 ++++++--
>  tools/pounder21/default-tests.tar.gz            |  Bin 1441 -> 0 bytes
>  tools/pounder21/fast-tests.tar.gz               |  Bin 1292 -> 0 bytes
>  tools/pounder21/pounder                         |  174 ++++++++++++++++++-----
>  tools/pounder21/schedulers/default-tests.tar.gz |  Bin 0 -> 1663 bytes
>  tools/pounder21/schedulers/fast-tests.tar.gz    |  Bin 0 -> 1494 bytes
>  tools/pounder21/schedulers/test-tests.tar.gz    |  Bin 0 -> 1057 bytes
>  tools/pounder21/test-tests.tar.gz               |  Bin 1006 -> 0 bytes
>  tools/pounder21/testall-tests.tar.gz            |  Bin 314 -> 0 bytes
>  9 files changed, 186 insertions(+), 51 deletions(-)
>  delete mode 100644 tools/pounder21/default-tests.tar.gz
>  delete mode 100644 tools/pounder21/fast-tests.tar.gz
>  create mode 100644 tools/pounder21/schedulers/default-tests.tar.gz
>  create mode 100644 tools/pounder21/schedulers/fast-tests.tar.gz
>  create mode 100644 tools/pounder21/schedulers/test-tests.tar.gz
>  delete mode 100644 tools/pounder21/test-tests.tar.gz
>  delete mode 100644 tools/pounder21/testall-tests.tar.gz

I'm not happy to have tarballs stored in the git for several reasons. Is
this really needed? Shouldn't having directories with files serve the
same purpose?

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list