linux_dsm_epyc7002

mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-28 11:18:45 +07:00

History

Shuah Khan 283ac6d5fb selftests: Fix test errors related to lib.mk khdr target Commit `b2d35fa5fc` ("selftests: add headers_install to lib.mk") added khdr target to run headers_install target from the main Makefile. The logic uses KSFT_KHDR_INSTALL and top_srcdir as controls to initialize variables and include files to run headers_install from the top level Makefile. There are a few problems with this logic. 1. Exposes top_srcdir to all tests 2. Common logic impacts all tests 3. Uses KSFT_KHDR_INSTALL, top_srcdir, and khdr in an adhoc way. Tests add "khdr" dependency in their Makefiles to TEST_PROGS_EXTENDED in some cases, and STATIC_LIBS in other cases. This makes this framework confusing to use. The common logic that runs for all tests even when KSFT_KHDR_INSTALL isn't defined by the test. top_srcdir is initialized to a default value when test doesn't initialize it. It works for all tests without a sub-dir structure and tests with sub-dir structure fail to build. e.g: make -C sparc64/drivers/ or make -C drivers/dma-buf ../../lib.mk:20: ../../../../scripts/subarch.include: No such file or directory make: *** No rule to make target '../../../../scripts/subarch.include'. Stop. There is no reason to require all tests to define top_srcdir and there is no need to require tests to add khdr dependency using adhoc changes to TEST_* and other variables. Fix it with a consistent use of KSFT_KHDR_INSTALL and top_srcdir from tests that have the dependency on headers_install. Change common logic to include khdr target define and "all" target with dependency on khdr when KSFT_KHDR_INSTALL is defined. Only tests that have dependency on headers_install have to define just the KSFT_KHDR_INSTALL, and top_srcdir variables and there is no need to specify khdr dependency in the test Makefiles. Fixes: `b2d35fa5fc` ("selftests: add headers_install to lib.mk") Cc: stable@vger.kernel.org Signed-off-by: Shuah Khan <shuah@kernel.org> Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com> Reviewed-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Shuah Khan <shuah@kernel.org>		2018-12-17 09:17:55 -07:00
..
functional	selftests: Fix test errors related to lib.mk khdr target	2018-12-17 09:17:55 -07:00
include	selftests: futex: convert test to use ksft TAP13 framework	2017-08-16 17:45:00 -06:00
Makefile	selftests: futex: delete RUN_TESTS and EMIT_TESTS overrides	2018-05-30 15:21:52 -06:00
README	docs: fix locations of several documents that got moved	2016-10-24 08:12:35 -02:00
run.sh	selftests/futex: Check ANSI terminal color support	2016-10-11 07:38:36 -06:00

README

Futex Test
==========
Futex Test is intended to thoroughly test the Linux kernel futex system call
API.

Functional tests shall test the documented behavior of the futex operation
code under test. This includes checking for proper behavior under normal use,
odd corner cases, regression tests, and abject abuse and misuse.

Futextest will also provide example implementation of mutual exclusion
primitives. These can be used as is in user applications or can serve as
examples for system libraries. These will likely be added to either a new lib/
directory or purely as header files under include/, I'm leaning toward the
latter.

Quick Start
-----------
# make
# ./run.sh

Design and Implementation Goals
-------------------------------
o Tests should be as self contained as is practical so as to facilitate sharing
  the individual tests on mailing list discussions and bug reports.
o The build system shall remain as simple as possible, avoiding any archive or
  shared object building and linking.
o Where possible, any helper functions or other package-wide code shall be
  implemented in header files, avoiding the need to compile intermediate object
  files.
o External dependencies shall remain as minimal as possible. Currently gcc
  and glibc are the only dependencies.
o Tests return 0 for success and < 0 for failure.

Output Formatting
-----------------
Test output shall be easily parsable by both human and machine. Title and
results are printed to stdout, while intermediate ERROR or FAIL messages are
sent to stderr. Tests shall support the -c option to print PASS, FAIL, and
ERROR strings in color for easy visual parsing. Output shall conform to the
following format:

test_name: Description of the test
	Arguments: arg1=val1 #units specified for clarity where appropriate
	ERROR: Description of unexpected error
	 FAIL: Reason for test failure
	# FIXME: Perhaps an " INFO: informational message" option would be
	#        useful here. Using -v to toggle it them on and off, as with -c.
	# there may be multiple ERROR or FAIL messages
Result: (PASS|FAIL|ERROR)

Naming
------
o FIXME: decide on a sane test naming scheme.  Currently the tests are named
  based on the primary futex operation they test. Eventually this will become a
  problem as we intend to write multiple tests which collide in this namespace.
  Perhaps something like "wait-wake-1" "wait-wake-2" is adequate, leaving the
  detailed description in the test source and the output.

Coding Style
------------
o The Futex Test project adheres to the coding standards set forth by Linux
  kernel as defined in the Linux source Documentation/process/coding-style.rst.