Remove whitespace at end of line
This is a scripted change done using the following command:
find . -type d -name .git -prune -o \
-type f \! -name \*\~ \! -name .\#\* \
\! -name \*.gz \! -name \*.pdf \! -name \*.patch -print0 | \
xargs -0 sed -i -e 's/[\t ]*$//'
Signed-off-by: Chris Dearman <chris@mips.com>
diff --git a/doc/ltp-howto.txt b/doc/ltp-howto.txt
index cb1d33a..0f53894 100644
--- a/doc/ltp-howto.txt
+++ b/doc/ltp-howto.txt
@@ -2,7 +2,7 @@
Linux Test Project HOWTO
-10 October 2000
+10 October 2000
Nate Straz
@@ -18,61 +18,61 @@
This document was written to help bring the community up
to speed on the ins and outs of the Linux Test Project.
-1.1 Copyright
+1.1 Copyright
-Copyright (c) 2000 by SGI, Inc.
+Copyright (c) 2000 by SGI, Inc.
Please freely copy and distribute (sell or give away) this
document in any format. It's requested that corrections
and/or comments be fowarded to the document maintainer.
You may create a derivative work and distribute it provided
-that you:
+that you:
* Send your derivative work (in the most suitable format
such as sgml) to the LDP (Linux Documentation Project)
or the like for posting on the Internet. If not the LDP,
- then let the LDP know where it is available.
+ then let the LDP know where it is available.
* License the derivative work with this same license or use
GPL. Include a copyright notice and at least a pointer
- to the license used.
+ to the license used.
-* Give due credit to previous authors and major contributors.
+* Give due credit to previous authors and major contributors.
If you're considering making a derived work other than a
translation, it's requested that you discuss your plans
-with the current maintainer.
+with the current maintainer.
-1.2 Disclaimer
+1.2 Disclaimer
Use the information in this document at your own risk. I
disavow any potential liability for the contents of this
document. Use of the concepts, examples, and/or other content
-of this document is entirely at your own risk.
+of this document is entirely at your own risk.
All copyrights are owned by their owners, unless specifically
noted otherwise. Use of a term in this document should
not be regarded as affecting the validity of any trademark
-or service mark.
+or service mark.
Naming of particular products or brands should not be seen
-as endorsements.
+as endorsements.
You are strongly recommended to take a backup of your system
-before major installation and backups at regular intervals.
+before major installation and backups at regular intervals.
-2 Introduction
+2 Introduction
-2.1 What is the Linux Test Project?
+2.1 What is the Linux Test Project?
The Linux Test Project (LTP) is an effort to create a set
of tools and tests to verify the functionality and stability
of the Linux kernel. We hope this will support Linux development
by making unit testing more complete and minimizing user
impact by building a barrier to keep bugs from making it
-to the user.
+to the user.
-2.2 What is wrong with the current testing model?
+2.2 What is wrong with the current testing model?
The Linux development community utilizes two important (some
out argue most important) testing techniques in its normal
@@ -84,31 +84,31 @@
is that of interaction of features. With a continuously
improving set of tests and tools, developers can get an
indication of whether their changes may have broken some
-other functionality.
+other functionality.
There is no such thing as a perfect test base. It is only
useful it if keeps up with new and changing functionality,
-and if it actually gets used.
+and if it actually gets used.
-2.3 Are you doing benchmarking?
+2.3 Are you doing benchmarking?
Not at this time. We are more interested in functional,
regression, and stress testing the Linux kernel. Benchmarking
may be workable to compare the performance among kernel
-versions.
+versions.
-2.4 Are you doing standards testing?
+2.4 Are you doing standards testing?
No, we are leaving that to the Linux Standards Base (LSB).
See the Linux Standards Base [http://www.linuxbase.org/||web site]
-for more information.
+for more information.
-3 Structure
+3 Structure
The basic building block of the test project is a test case
that consists of a single action and a verification that
the action worked. The result of the test case is usually
-restricted to PASS/FAIL.
+restricted to PASS/FAIL.
A test program is a runnable program that contains one or
more test cases. Test programs often understand command
@@ -121,16 +121,16 @@
program and a set of command line options. Test tags are
the basis for test suites.
-4 Writing Tests
+4 Writing Tests
Writing a test case is a lot easier than most people think.
Any code that you write to examine how a part of the kernel
works can be adapted into a test case. All that is needed
is a way to report the result of the action to the rest
of the world. There are several ways of doing this, some
-more involved than others.
+more involved than others.
-4.1 Exit Style Tests
+4.1 Exit Style Tests
Probably the simplest way of reporting the results of a test
case is the exit status of your program. If your test program
@@ -140,26 +140,26 @@
status, i.e. exit(0). Any test driver should be able to
handle this type of error reporting. If a test program has
multiple test cases you won't know which test case failed,
-but you will know the program that failed.
+but you will know the program that failed.
-4.2 Formatted Output Tests
+4.2 Formatted Output Tests
The next easiest way of reporting the results is to write
the results of each test case to standard output. This allows
for the testing results to be more understandable to both
the tester and the analysis tools. When the results are
written in a standard way, tools can be used to analyze
-the results.
+the results.
5 Testing Tools
The Linux Test Project has not yet decided on a "final" test
harness. We have provided a simple solution with ltp-pan to
make due until a complete solution has been found/created
-that compliments the Linux kernel development process.
+that compliments the Linux kernel development process.
Several people have said we should use such and such a test
harness. Until we find we need a large complex test harness,
-we will apply the KISS concept.
+we will apply the KISS concept.
5.1 Ltp-pan
@@ -182,18 +182,18 @@
ltp-pan will overwrite the first character with a '#'. The active
file can be shared between multiple instances of ltp-pan so
you know which tests were running when the system crashes
-by looking at one file.
+by looking at one file.
A ltp-pan file contains a list of test tags for ltp-pan to run. The
format of a ltp-pan file is as follows:
testtag testprogram -o one -p two other command line options
-# This is a comment. It is a good idea to describe the test
+# This is a comment. It is a good idea to describe the test
-# tags in your ltp-pan file. Tests programs can have different
+# tags in your ltp-pan file. Tests programs can have different
-# behaviors depending on the command line options so it is
+# behaviors depending on the command line options so it is
# helpful to describe what each test tag is meant to verify
or # provoke.
@@ -204,7 +204,7 @@
# 40 Mb mmap() test.
-# Creates a 10000 page mmap, touches all of the map, sync's
+# Creates a 10000 page mmap, touches all of the map, sync's
# it, and munmap()s it.
@@ -218,7 +218,7 @@
# Negative test for dup(2) with bad fd
-kill09 kill09
+kill09 kill09
# Basic test for kill(2)
@@ -237,11 +237,11 @@
The most basic way to run ltp-pan is by passing the test program
and parameters on the command line. This will run the single
-program once and wrap the output.
+program once and wrap the output.
$ ltp-pan -a ltp.zoo -n tutor sleep 4
-<<<test_start>>>
+<<<test_start>>>
tag=cmdln stime=971450564
@@ -264,11 +264,11 @@
$ cat ltp.zoo
-#9357,tutor,pan/ltp-pan -a ltp.zoo -n tutor sleep 4
+#9357,tutor,pan/ltp-pan -a ltp.zoo -n tutor sleep 4
#9358,cmdln,sleep 4
-$
+$
How it works
@@ -278,7 +278,7 @@
parameters that ltp-pan should run. This test is given the tag
"cmdln." Ltp-pan will run one test randomly, which ends
up being cmdln since it is the only test that we told ltp-pan
-about.
+about.
In the active file, ltp.zoo, ltp-pan writes the pid, test tag,
and part of the command line for the currently running tests.
@@ -291,7 +291,7 @@
We have run one test once. Let's do something a little more
exciting. Let's run one test several times, at the same
-time.
+time.
$ ltp-pan -a ltp.zoo -n tutor -x 3 -s 3 -O /tmp sleep 1
@@ -309,7 +309,7 @@
<<<test_output>>>
-
+
<<<execution_status>>>
@@ -334,7 +334,7 @@
<<<test_output>>>
-
+
<<<execution_status>>>
@@ -359,7 +359,7 @@
<<<test_output>>>
-
+
<<<execution_status>>>
@@ -378,7 +378,7 @@
a directory where temporary files can be created to buffer
the output of each test tag. You can see in the output that
cmdln ran three times. If the -O option were omitted, your
-test output would be mixed, making it almost worthless.
+test output would be mixed, making it almost worthless.
* Using a ltp-pan file to run multiple tests
@@ -391,42 +391,42 @@
Ltp-scanner is a results analysis tool that understands the rts
style output which ltp-pan generates by default. It will produce
a table summarizing which tests passed and which failed.
-
+
5.3 The Quick-hitter Package
Many of the tests released use the Quick-hitter test package
to perform tasks like create and move to a temporary directory,
handle some common command line parameters, loop, run in
-parallel, handle signals, and clean up.
+parallel, handle signals, and clean up.
There is an example test case, doc/examples/quickhit.c, which
shows how the quick-hitter package can be used. The file
is meant to be a supplement to the documentation, not a
working test case. Use any of the tests in tests/ as a template.
-6 To Do
+6 To Do
There are a lot of things that still need to be done to make
this a complete kernel testing system. The following sections
-will discuss some of the to do items in detail.
+will discuss some of the to do items in detail.
-6.1 Configuration Analysis
+6.1 Configuration Analysis
While the number of configuration options for the Linux kernel
is seen as a strength to developers and users alike, it
is a curse to testers. To create a powerful automated testing
system, we need to be able to determine what the configuration
on the booted box is and then determine which tests should
-be run on that box.
+be run on that box.
The Linux kernel has hundreds of configuration options that
can be set to compile the kernel. There are more options
that can be set when you boot the kernel and while it is
running. There are also many patches that can be applied
-to the kernel to add functionality or change behavior.
+to the kernel to add functionality or change behavior.
-6.2 Result Comparison
+6.2 Result Comparison
A lot of testing will be done in the life of the Linux Test
Project. Keeping track of the results from all the testing
@@ -434,43 +434,43 @@
that output from a test machine, feed it to a program and
receive a list of items that broke since the last run on
that machine, or were fixed, or work on another test machine
-but not on this one.
+but not on this one.
-7 Contact information and updates
+7 Contact information and updates
URL: http://ltp.sourceforge.net/
-mailing list: ltp-list@lists.sourceforge.net
+mailing list: ltp-list@lists.sourceforge.net
list archive: https://sourceforge.net/mailarchive/forum.php?forum_name=ltp-list
Questions and comments should be sent to the LTP mailing
list at ltp-list@lists.sourceforge.net. To subscribe, please go to
-https://lists.sourceforge.net/lists/listinfo/ltp-list.
+https://lists.sourceforge.net/lists/listinfo/ltp-list.
The source is also available via CVS. See the web site for
-a web interface and check out instructions.
+a web interface and check out instructions.
-8 Glossary
+8 Glossary
Test IEEE/ANSI([footnote] Kit, Edward, Software Testing in the Real World:
-Improving the Process. P. 82. ACM Press, 1995.) :
+Improving the Process. P. 82. ACM Press, 1995.) :
(i) An activity in which a system or component is executed
under specified conditions, the results are observed or
record, and an evaluation is made of some aspect of the
-system or component.
- (ii) A set of one or more test cases.
+system or component.
+ (ii) A set of one or more test cases.
Test Case A test assertion with a single result that
is being verified. This allows designations such as PASS
or FAIL to be applied to a single bit of functionality.
A single test case may be one of many test cases for
- testing the complete functionality of a system.
- IEEE/ANSI:
+ testing the complete functionality of a system.
+ IEEE/ANSI:
(i)A set of test inputs, execution conditions, and expected
- results developed for a particular objective.
+ results developed for a particular objective.
(ii) The smallest entity that is always executed as a unit,
- from beginning to end.
+ from beginning to end.
Test Driver A program that handles the execution of
test programs. It is responsible for starting the test
@@ -480,22 +480,22 @@
Test Framework A mechanism for organizing a group of
tests. Frameworks may have complex or very simple API's,
drivers and result logging mechanisms. Examples of frameworks
- are TETware and DejaGnu.
+ are TETware and DejaGnu.
Test Harness A Test harness is the mechanism that connects
a test program to a test framework. It may be a specification
of exit codes, or a set of libraries for formatting messages
and determining exit codes. In TETware, the tet_result()
- API is the test harness.
+ API is the test harness.
Test Program A single invokable program. A test program
can contain one or more test cases. The test harness's
API allows for reporting/analysis of the individual test
- cases.
+ cases.
Test Suite A collection of tests programs, assertions,
- cases grouped together under a framework.
+ cases grouped together under a framework.
Test Tag An identifier that corresponds to a command
line which runs a test. The tag is a single word that
- matches a test program with a set of command line arguments.
+ matches a test program with a set of command line arguments.