ADR Definition Document for a RAD Module
The top-level element in an ADR definition document is an api
. The api
element has one mandatory attribute, name
, which is used to name the output files. The element contains one or more derived type definitions or interface definitions. Note that either a derived type or an interface must be defined.
Three derived types are available for definition and use by interfaces: a structured type that can be defined with a struct
element, an enumeration type that can be defined with an enum
element, and a dictionary type that can be defined with a dictionary
element. Interfaces are defined using interface
elements. The derived types defined in an API document are available for use by all interfaces defined in that document.
The following is an example of an API.
Example 2-1 Skeleton RAD Module document
<api xmlns="https://xmlns.oracle.com/radadr" name="com.oracle.solaris.rad.example" register="true"> <summary> An API Example </summary> <doc>...</doc> <version/> <struct>...</struct> <struct>...</struct> <enum>...</enum> <interface>...</interface> <interface>...</interface> </api>
The xmlns
line is required to indicate the type of the XML document. The name
attribute identifies the name of the API, the namespace within which all subsidiary interfaces are to be found. Additional attributes can assist in the generation of server module code.
The register attribute is a boolean, which is optional and true by default. If true, then radadrgen
automatically generates a _rad_reg function when generating server implementation code. If false, the function is not generated and the module author will need to provide a _rad_reg function. This option is primarily used to create special types of modules, such as protocol or transport modules. In general, it does not need to be specified, because the default generated function is enough for most purposes.