tools/testing/selftests/arm64/README

Source file repositories/reference/linux-study-clean/tools/testing/selftests/arm64/README

File Facts

System: Linux kernel
Corpus path: tools/testing/selftests/arm64/README
Extension: [no extension]
Size: 879 bytes
Lines: 26
Domain: Support Tooling And Documentation
Bucket: tools
Inferred role: Support Tooling And Documentation: tools
Status: atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

No C-style include directives detected by the generator.

Detected Declarations

No top-level syscall, struct, function, initcall, or export declaration detected by the generator.

Annotated Snippet

KSelfTest ARM64
===============

- These tests are arm64 specific and so not built or run but just skipped
  completely when env-variable ARCH is found to be different than 'arm64'
  and `uname -m` reports other than 'aarch64'.

- Holding true the above, ARM64 KSFT tests can be run within the KSelfTest
  framework using standard Linux top-level-makefile targets:

      $ make TARGETS=arm64 kselftest-clean
      $ make TARGETS=arm64 kselftest

      or

      $ make -C tools/testing/selftests TARGETS=arm64 \
		INSTALL_PATH=<your-installation-path> install

      or, alternatively, only specific arm64/ subtargets can be picked:

      $ make -C tools/testing/selftests TARGETS=arm64 ARM64_SUBTARGETS="tags signal" \
		INSTALL_PATH=<your-installation-path> install

   Further details on building and running KFST can be found in:
     Documentation/dev-tools/kselftest.rst

Annotation

Atlas domain: Support Tooling And Documentation / tools.
Implementation status: atlas-only.

Implementation Notes

This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.