updated pan example
diff --git a/doc/examples/quickhit.c b/doc/examples/quickhit.c
index a9dd52b..43d2468 100644
--- a/doc/examples/quickhit.c
+++ b/doc/examples/quickhit.c
@@ -2,7 +2,6 @@
This is an example quickhitter test based on tests/link03.c. The comments
have been changed to explain how the quickhit package can be used
*/
-
/*
* Copyright (c) 2000 Silicon Graphics, Inc. All Rights Reserved.
*
@@ -35,7 +34,7 @@
* http://oss.sgi.com/projects/GenInfo/NoticeExplan/
*
*/
-/* $Id: quickhit.c,v 1.1 2000/10/09 20:25:12 nstraz Exp $ */
+/* $Id: quickhit.c,v 1.2 2000/10/10 21:57:51 nstraz Exp $ */
/**********************************************************
*
* OS Test - Silicon Graphics, Inc.
@@ -237,11 +236,21 @@
/*
* Call link(2)
*/
+ /* Use the TEST() macro to wrap your syscalls. It saves the return
+ * to TEST_RETURN and the errno to TEST_ERRNO
+ */
TEST(link(Fname, lname));
/* check return code */
if ( TEST_RETURN == -1 ) {
+ /* To gather stats on errnos returned, log the errno */
TEST_ERROR_LOG(TEST_ERRNO);
+ /* If you determine that testing shouldn't continue, report your
+ * results using tst_brkm(). The remaining test cases will be
+ * marked broken. TFAIL is the result type for a test failure,
+ * cleanup is the cleanup routine to call, and the rest is your
+ * message in printf form.
+ */
tst_brkm(TFAIL, cleanup, "link(%s, %s) Failed, errno=%d : %s",
Fname, lname, TEST_ERRNO, strerror(TEST_ERRNO));
}
@@ -260,6 +269,11 @@
if ( fbuf.st_nlink <= 1 || lbuf.st_nlink <= 1 ||
(fbuf.st_nlink != lbuf.st_nlink) ) {
+ /* When you have results to report, and testing can
+ * continue, use tst_resm() to record those results. Use
+ * TFAIL if the test case failed and your message in printf
+ * style.
+ */
tst_resm(TFAIL,
"link(%s, %s[1-%d]) ret %d for %d files, stat values do not match %d %d",
Fname, Basename, nlinks, TEST_RETURN, nlinks,
@@ -268,6 +282,7 @@
}
}
if ( cnt >= nlinks ) {
+ /* Here the test case passed so we use TPASS */
tst_resm(TPASS,
"link(%s, %s[1-%d]) ret %d for %d files, stat linkcounts match %d",
Fname, Basename, nlinks, TEST_RETURN, nlinks,
@@ -277,6 +292,8 @@
else
Tst_count++;
+ /* Here we clean up after the test case so we can do another iteration.
+ */
for(cnt=1; cnt < nlinks; cnt++) {
sprintf(lname, "%s%d", Basename, cnt);
diff --git a/doc/ltp-howto.lyx b/doc/ltp-howto.lyx
index 7019903..90ca548 100644
--- a/doc/ltp-howto.lyx
+++ b/doc/ltp-howto.lyx
@@ -30,7 +30,7 @@
Linux Test Project HOWTO
\layout Date
-4 October 2000
+10 October 2000
\layout Author
Nate Straz
@@ -263,7 +263,7 @@
\layout Subsection
-Pan and Scanner
+Pan
\layout Standard
@@ -277,7 +277,7 @@
pan
\family default
has the ability to run the test sequentially or randomly and in parallel
- while capturing test output and cleaning up orphanned processes.
+ while capturing test output and cleaning up orphaned processes.
\family typewriter
pan
@@ -286,6 +286,82 @@
\layout Standard
+A pan file contains a list of tests to run.
+ The format of a pan file is as follows:
+\layout Code
+
+testtag testprogram -o one -p two other command line options
+\layout Code
+
+# This is a comment.
+ It is a good idea to describe the test
+\layout Code
+
+# tags in your pan file.
+ Tests programs can have different
+\layout Code
+
+# behaviors depending on the command line options so it is
+\layout Code
+
+# helpful to describe what each test tag is meant to verify or
+\layout Code
+
+# provoke.
+\layout Code
+
+# Some more test cases
+\layout Code
+
+mm01 mmap001 -m 10000
+\layout Code
+
+# 40 Mb mmap() test.
+\layout Code
+
+# Creates a 10000 page mmap, touches all of the map, sync's
+\layout Code
+
+# it, and munmap()s it.
+\layout Code
+
+mm03 mmap001 -i 0 -I 1 -m 100
+\layout Code
+
+# repetitive mmapping test.
+\layout Code
+
+# Creates a one page map repetitively for one minute.
+\layout Code
+
+dup02 dup02
+\layout Code
+
+# Negative test for dup(2) with bad fd
+\layout Code
+
+kill09 kill09
+\layout Code
+
+# Basic test for kill(2)
+\layout Code
+
+fs-suite01 pan -e -a fs-suite01.zoo -n fs-suite01 -f runtest/fs
+\layout Code
+
+# run the entire set of file system tests
+\layout Standard
+
+For more information on pan see the man page
+\family typewriter
+doc/man1/pan.1
+\family default
+.
+\layout Subsection
+
+Scanner
+\layout Standard
+
\family typewriter
scanner
@@ -301,28 +377,36 @@
generates by default.
It will produce a table summarizing which tests passed and which failed.
-\layout Subsubsection
-
-Example with Pan
-\layout Standard
-
-This would be a Good Thing(tm) to have.
- Show off the nesting that can be done with Pan
\layout Subsection
-The Quickhitter Package
+The Quick-hitter Package
\layout Standard
-Many of the tests released use the Quickhitter 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.
+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.
+\layout Standard
+
+There is an example test case,
+\family typewriter
+doc/examples/quickhit.c
+\family default
+, 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
+\family typewriter
+tests/
+\family default
+ as a template.
\layout Section
To Do
\layout Standard
-There are a lot of things that still need to be doine to make this a complete
+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.
@@ -461,7 +545,7 @@
\layout Description
Test\SpecialChar ~
-Framework A mechanism for organising a group of tests.
+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.