This document is a description of the Fuchsia Interface Definition Language (FIDL) purpose, high-level goals, and requirements.
The Fuchsia Interface Definition Language (FIDL) is the language used to describe interprocess communication (IPC) protocols used by programs running on the Fuchsia Operating System. FIDL is supported by a toolchain (compiler) and runtime support libraries (bindings) to help developers use IPC effectively.
Goals
Fuchsia extensively relies on IPC since it has a microkernel architecture wherein most functionality is implemented in user space outside of the kernel, including privileged components such as device drivers. Consequently the IPC mechanism must be efficient, deterministic, robust, and easy to use.
IPC efficiency pertains to the computational overhead required to generate, transfer, and consume messages between processes. IPC will be involved in all aspects of system operation so it must be efficient. The FIDL compiler must generate tight code without excess indirection or hidden costs. It should be at least as good as hand-rolled code would be where it matters most.
IPC determinism pertains to the ability to perform transactions within a known resource envelope. IPC will be used extensively by critical system services such as filesystems which serve many clients and which must perform in predictable ways. The FIDL wire format must offer strong static guarantees such as ensuring that structure size and layout is invariant thereby alleviating the need for dynamic memory allocation or complex validation rules.
IPC robustness pertains to the need to consider IPC as an essential part of the operating system's ABI. Maintaining binary stability is crucial. Mechanisms for protocol evolution must be designed conservatively so as not to violate the invariants of existing services and their clients, particularly when the need for determinism is also considered. The FIDL bindings must perform effective, lightweight, and strict validation.
IPC ease of use pertains to the fact that IPC protocols are an essential part of the operating system's API. It is important to provide good developer ergonomics for accessing services via IPC. The FIDL code generator removes the burden of writing IPC bindings by hand. Moreover, the FIDL code generator can produce different bindings to suit the needs of different audiences and their idioms.
TODO: express goal of meeting the needs of different audiences using appropriately tailored bindings, eg. system programming native vs. event-driven dispatch vs. async calls, etc... say more things about FIDL as our system API, SDK concerns, etc.
Requirements
Compiler is written in C++ to be usable by components built in Zircon.
Compiler is portable and can be built with a host toolchain.
We will not support FIDL bindings for any platform other than Fuchsia.
The FIDL wire format specified how FIDL messages are represented in memory for transmission over IPC.
The FIDL wire format is documented Wire Format Specification.
The FIDL language is the syntax by which protocols are described in *.fidl files.
The FIDL language is documented Language Specification.
The FIDL compiler generates code for programs to use and implement protocols described by the FIDL language.
The FIDL compiler is documented Compiler Specification.
FIDL bindings are language-specific runtime support libraries and code generators which provide APIs for manipulating FIDL data structures and protocols.
Languages-specific topics:
Bindings are available in various flavors depending on the language:
Bindings offer several various ways of invoking protocol methods depending on the language:
Bindings provide some or all of the following principal operations:
This section describes the workflow of authors, publishers, and consumers of IPC protocols described using FIDL.
The author of a FIDL based protocol creates one or more *.fidl files to describe their data structures, protocols, and methods.
FIDL files are grouped into one or more FIDL libraries by the author. Each library represents a group of logically related functionality with a unique library name. FIDL files within the same library implicitly have access to all other declarations within the same library. The order of declarations within the FIDL files that make up a library is not significant.
FIDL files of one library can access declarations within another FIDL library by importing the other FIDL module. Importing other FIDL libraries makes their symbols available for use thereby enabling the construction of protocols derived from them. Imported symbols must be qualified by the library name or by an alias to prevent namespace collisions.
The publisher of a FIDL based protocol is responsible for making FIDL libraries available to consumers. For example, the author may disseminate FIDL libraries in a public source repository or distribute them as part of an SDK.
Consumers need only point the FIDL compiler at the directory which contains the FIDL files for a library (and its dependencies) to generate code for that library. The precise details for how this is done will generally be addressed by the consumer's build system.
The consumer of a FIDL based protocol uses the FIDL compiler to generate code suitable for use with their language runtime specific bindings. For certain language runtimes, the consumer may have a choice of a few different flavors of generated code all of which are interoperable at the wire format level but perhaps not at the source level.
In the Fuchsia world build environment, generating code from FIDL libraries will be done automatically for all relevant languages by individual FIDL build targets for each library.
In the Fuchsia SDK environment, generating code from FIDL libraries will be done as part of compiling the applications which use them.
