ktests wiki: breakpoints: basic description, compilation tips #336
+256
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Another tests collection to expose:
breakpoints.TLDR: There are only two tests. The
step_after_suspend_testwon't work when run in qemu so it can (and should) be skipped. Thebreakpoint_test(and its arm64 equivalentbreakpoint_test_arm64) has some compilation gimmicks but once built it should run fine and always pass. Moreover, it's testing a rather important functionality of the kernel as well as being quick and straightforward, so it's a good candidate to be included in the sanity checks.Sidenote
I'll need to systematize this effort a bit or nothing productive will come out of it as there are too many tests (~200-300) and at the current speed dictated by the stolen time between CVEs covering them all will take me years.
The overarching goal is to define a good sanity check tests suite.
For this it makes sense to pick the tests in the order of how essential the subsystems are which they test. In this way a good sanity tests suite should be found way before all the tests are examined. Finding out which tests are essential is part of examining them though, so I'll use a small heuristic and research the tests in the order of when they were introduced to the code base chronologically. Hopefully the kernel devs were testing the essential features first, too.
Here's a table of all makefiles from the
tools/testing/selftests/trunk, ordered by their creation commit date. It should be of use if anyone else wished to join the effort of examining the selftests so that we know what we're actually doing: