From: Avinesh Kumar <akumar@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] lib: Improve doc
Date: Wed, 3 Jan 2024 12:20:18 +0100 [thread overview]
Message-ID: <20240103112023.32355-1-akumar@suse.de> (raw)
Signed-off-by: Avinesh Kumar <akumar@suse.de>
---
lib/README.md | 33 ++++++++++++++++-----------------
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/lib/README.md b/lib/README.md
index ccb1cf1da..bfc05ae07 100644
--- a/lib/README.md
+++ b/lib/README.md
@@ -27,16 +27,16 @@
When a test is executed the very first thing to happen is that we check for
various test prerequisites. These are described in the tst\_test structure and
-range from simple '.require\_root' to a more complicated kernel .config boolean
+range from simple '.needs\_root' to a more complicated kernel .config boolean
expressions such as: "CONFIG\_X86\_INTEL\_UMIP=y | CONFIG\_X86\_UMIP=y".
-If all checks are passed the process carries on with setting up the test
+If all checks are passed, the process continues with setting up the test
environment as requested in the tst\_test structure. There are many different
setup steps that have been put into the test library again ranging from rather
simple creation of a unique test temporary directory to a bit more complicated
ones such as preparing, formatting, and mounting a block device.
-The test library also intializes shrared memory used for IPC at this step.
+The test library also initializes shared memory used for IPC at this step.
Once all the prerequisites are checked and test environment has been prepared
we can move on executing the testcase itself. The actual test is executed in a
@@ -62,12 +62,11 @@ for test_variants:
fork_testrun()
```
-Before we fork() the test process the test library sets up a timeout alarm and
-also a heartbeat signal handlers and also sets up an alarm(2) accordingly to
-the test timeout. When a test times out the test library gets SIGALRM and the
-alarm handler mercilessly kills all forked children by sending SIGKILL to the
-whole process group. The heartbeat handler is used by the test process to reset
-this timer for example when the test functions run in a loop.
+Before we fork() the test process, the test library sets up a timeout alarm and
+also a heartbeat signal handler. When a test times out, the test library gets
+SIGALRM and the alarm handler mercilessly kills all forked children by sending
+SIGKILL to the whole process group. The heartbeat handler is used by the test
+process to reset this timer for example when the test functions run in a loop.
With that done we finally fork() the test process. The test process firstly
resets signal handlers and sets its pid to be a process group leader so that we
@@ -97,14 +96,14 @@ usually better option than exiting it in the middle.
The test cleanup() is also called by the tst\_brk() handler in order to cleanup
before exiting the test process, hence it must be able to cope even with
partial test setup. Usually it suffices to make sure to clean up only
-resources that already have been set up and to do that in an inverse order that
-we did in setup().
+resources that already have been set up and to do that in the reverse order
+that we did in setup().
Once the test process exits or leaves the run() or run\_all() function the test
library wakes up from the waitpid() call, and checks if the test process
exited normally.
-Once the testrun is finished the test library does a cleanup() as well to clean
+Once the testrun is finished, the test library does a cleanup() as well to clean
up resources set up in the test library setup(), reports test results and
finally exits the process.
@@ -126,8 +125,8 @@ This especially means that:
- While the test results are, by the design, propagated to the test library
we may still miss a child that gets killed by a signal or exits unexpectedly.
-The test writer should, because of this, take care for reaping these proceses
-properly, in most cases this could be simply done by calling
+The test writer should, because of this, take care fofor reaping these
+processes properly, in most cases this could be simply done by calling
tst\_reap\_children() to collect and dissect deceased.
Also note that tst\_brk() does exit only the current process, so if a child
@@ -136,9 +135,9 @@ exits.
### Test library and exec()
-The piece of mapped memory to store the results to is not preserved over
+The piece of mapped memory to store the results is not preserved over
exec(2), hence to use the test library from a binary started by an exec() it
-has to be remaped. In this case the process must to call tst\_reinit() before
+has to be remapped. In this case, the process must call tst\_reinit() before
calling any other library functions. In order to make this happen the program
environment carries LTP\_IPC\_PATH variable with a path to the backing file on
tmpfs. This also allows us to use the test library from shell testcases.
@@ -148,5 +147,5 @@ tmpfs. This also allows us to use the test library from shell testcases.
The piece of mapped memory is also used as a base for a futex-based
synchronization primitives called checkpoints. And as said previously the
memory can be mapped to any process by calling the tst\_reinit() function. As a
-matter of a fact there is even a tst\_checkpoint binary that allows us to use
+matter of a fact, there is even a tst\_checkpoint binary that allows us to use
the checkpoints from shell code as well.
--
2.43.0
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next reply other threads:[~2024-01-03 11:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 11:20 Avinesh Kumar [this message]
2024-01-03 11:22 ` [LTP] [PATCH] lib: Improve doc Avinesh Kumar
2024-01-03 11:25 ` [LTP] [PATCH v2] " Avinesh Kumar
2024-01-03 12:55 ` Petr Vorel
2024-01-03 19:17 ` [LTP] [PATCH v3] " Avinesh Kumar
2024-01-04 11:17 ` Petr Vorel
2024-01-03 19:20 ` [LTP] [PATCH v2] " Avinesh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240103112023.32355-1-akumar@suse.de \
--to=akumar@suse.de \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox