The NASD tree provides a rich internal API, including definitions for many basic and complex types, a threads interface, a memory management interface, various timing and synchronization primitives, and more. It is important for all code that is made part of this tree to take full advantage of this API. This provides increased and simplified portability, greater ability to debug, better compatibility between modules, and code which is easier for others to read. Sections which follow will detail this API. This section describes various generalities, and some of the basic philosophy.
All NASD source files should begin with a comment naming the file, and
a brief (one or two line) description of the file's purpose. A
copyright
should immediately follow this. All source files should also include
<nasd/nasd_options.h>
before including other files.
This includes header files. This may seem redundant, but greatly eases
debugging, and enables certain automatic processing of the code. All
drive-specific files should also include <nasd/nasd_drive_options.h>
.
For all files that are compiled into libraries, the drive, various kernels, or
are otherwise not explicitly part of some user-level front-end to NASD functionality,
any globally-defined symbols should be prefixed with nasd_.
Likewise,
any defined types should be similarly prefixed. This makes porting, profiling, and
debugging the code much easier. Globally-defined symbols include any non-static
functions and variables.
It is also the convention that all defined types are postfixed with _t
.
Thus, a properly formed type "something" would be nasd_something_t
.
For the purposes of this documentation, the term module will be defined as the set of code that implements a specific set of functionalities, regardless of how many files are required for this implementation. For instance, the code which provides memory allocation and deallocation is a module. More information on modules is available in a separate section.
Functions that are not local to any specific module should always return a
result type nasd_status_t
. This type is documented in detail in
the section on results and errors. This
presents a single, unified manner in which operations may indicate success or
failure to their callers, as well as ways in which they might express the
nature of the failure (i.e., resource shortage versus internal data corruption
versus malformed arguments) so that the caller might better respond.
![]() | ![]() | ![]() |
---|---|---|
Running NASD-NFS clients | Basic types | NASD Programmer's Documentation |