There are four categories of headers: system, global, library, and implementation.
These headers define the interface between the kernel and userspace, also known as the vDSO interface. These headers define system calls, included related types and structures. These headers also define some basic C and C++ machinery, for example for crashing in a well-defined sequence.
- System headers may be installed under
zircon/, rather than
- System call wrappers, such as
zx, are not considered system headers. They are library headers (see below) that depend on the system headers.
- Standard system headers (e.g., from the C and C++ standard libraries) have their standard paths.
These headers define system-wide contracts between userspace components. These headers are generated from FIDL definitions of these contracts.
- Hand-written code should be presented in library headers rather than global headers.
Library headers are hand-written code that are used by applications. The interfaces they define are local to that application. Some libraries are Fuchsia-specific and provide an ergonomic wrapper around some lower-level system facilities. Some libraries might not be tied directly to Fuchsia.
- All library headers are in the
lib/directory to help avoid collisions with other header used by applications.
- Headers may not be placed straight under
lib/. Subdirectories (
lib/foo/) are mandatory.
Implementation headers are internal to the Fuchsia Platform Source Tree. They are never included in SDKs and are referenced by absolute path from the root of the source tree.
Tools which generate implementation headers place them in a parallel directory structure within the build directory, and users include them as if they were in the directory where their generation is defined in the build.
- Includes of implementation headers use
<to indicate that the path is relative to the root of the source tree.
fshost_config.h is generated by a target in