A CDM or HAM is loaded into file server memory as an NLM. Therefore, they need to provide the OS with standard NLM entry points for load-time module initialization and unload-time returning of system resources. Once initialized, CDMs and HAMs register themselves with NWPA specifying additional entry points for receiving I/O requests, and they must specify the type of devices (CDM) or host adapter interfaces (HAM) they support. In the case of a CDM, one of these entry points is an inquiry routine.
NWPA calls this routine following CDM registration, passing it two arguments. One is a Media Manager generated ID to a registered device matching the type for which the CDM registered, and the other is a handle to the HAM receiving requests for that device. Within the context of the inquiry routine, the CDM determines if it will support the device. If the CDM decides to support the device, it makes a CDI call and binds itself to the device. Binding means that the CDM tells NWPA that it is the module accepting I/O requests for the specified device, and what functions it supports for that device. In order to bind to a device, the CDM must generate a local bindhandle for the device and pass it as an argument in the CDI call. NWPA associates the bindhandle to the device in its object database and, from that time forward, uses the bindhandle to identify that device when talking with that particular CDM. NWPA makes subsequent calls to a CDM's inquiry routine whenever a new device object matching the CDM's device type is created.
During its initialization routine, a HAM scans hardware slots for adapters matching the bus-protocol it is designed to support. When a matched adapter is found, the HAM generates a unique HAM handle for the adapter. For adapters that provide more than one bus, the HAM must generate a HAM handle for each bus instance. A HAM can be designed to support either single or multiple adapters made by a single manufacturer or multiple adapters made by different manufacturers as long as each adapter matches the HAM's bus protocol type.
To conclude its initialization, a HAM registers a HAM handle and a pair of I/O entry points with NWPA via a call to a HAI routine for each adapter/bus instance it will support. One of the entry points is for receiving and routing I/O requests to the appropriate adapter/bus and its attached devices. The other is for handling aborts on pending requests in a specified device's queue. As an example, if a HAM supports an adapter having two buses, the HAM must register a HAM handle and entry point pair twice, once for the first bus and again for the second bus. The HAM handle in each registration must be unique for each bus; however, the HAM has the option of specifying either the same, or a different, entry point pair in each registration. Typically, a HAM will have only one pair of I/O entry points to handle I/O routing to adapters and their devices. After module initialization and registration of its entry points, the HAM is ready to accept HACB I/O requests. At this point, the HAM waits until it receives its first I/O request from NWPA. This first request calls HAM_Return_Bus_Info (Function 0x00). After this function is completed, the HAM waits until a Scan For New Devices request occurs. During the context of this scan request, the HAM scans each adapter or bus it supports and builds its device lists. The HAM must build a device list for each bus it supports and assign a handle to each device attached to a bus. Each device list should then be associated with its corresponding bus through the HAM handle. The HAM determines proper routing of a request by using the HAM handle to identify the proper adapter and bus. It then uses the device handle to index into the bus's device list to identify the proper device.
The following is an outline of the general flow of events in the architecture: