luckfox-pico-sdk/sysdrv/source/kernel/tools/testing/selftests/futex
luckfox-eng29 8f34c2760d project:build.sh: Added fastboot support; custom modifications to U-Boot and kernel implemented using patches.
project:cfg:BoardConfig_IPC: Added fastboot BoardConfig file and firmware post-scripts, distinguishing between
the BoardConfigs for Luckfox Pico Pro and Luckfox Pico Max. project:app: Added fastboot_client and rk_smart_door
for quick boot applications; updated rkipc app to adapt to the latest media library. media:samples: Added more
usage examples. media:rockit: Fixed bugs; removed support for retrieving data frames from VPSS. media:isp:
Updated rkaiq library and related tools to support connection to RKISP_Tuner. sysdrv:Makefile: Added support for
compiling drv_ko on Luckfox Pico Ultra W using Ubuntu; added support for custom root filesystem.
sysdrv:tools:board: Updated Buildroot optional mirror sources, updated some software versions, and stored device
tree files and configuration files that undergo multiple modifications for U-Boot and kernel separately.
sysdrv:source:mcu: Used RISC-V MCU SDK with RT-Thread system, mainly for initializing camera AE during quick
boot. sysdrv:source:uboot: Added support for fastboot; added high baud rate DDR bin for serial firmware upgrades.
sysdrv:source:kernel: Upgraded to version 5.10.160; increased NPU frequency for RV1106G3; added support for
fastboot.

Signed-off-by: luckfox-eng29 <eng29@luckfox.com>
2024-10-14 09:47:04 +08:00
..
functional project:build.sh: Added fastboot support; custom modifications to U-Boot and kernel implemented using patches. 2024-10-14 09:47:04 +08:00
include creat: first commit 2023-08-08 20:36:47 +08:00
Makefile creat: first commit 2023-08-08 20:36:47 +08:00
README creat: first commit 2023-08-08 20:36:47 +08:00
run.sh creat: first commit 2023-08-08 20:36:47 +08:00

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.