Two fields that are required to be supplied in every BDD are the BDD_Sync_Cmd_Proc and BDD_Command_Proc callback entry points. These fields specify a procedures to be called whenever a client sends commands to the fast disk device. Clients never call the entry points directly. Instead, clients send command chains to a fast disk device by calling the BlockDev_Synchronous_Command and BlockDev_Send_Command services.
Synchronous commands are passed directly to the fast disk device. These commands behave like normal procedure calls in that the result of the command is returned to the caller when the procedure call returns (BlockDev_Send_Command has no return results).
Currently, the only defined command is BD_SC_Get_Version. All fast disk devices must support this command. The synchronous command ID is always placed in the AX register. Independent Software Vendors (ISV) may support device-dependent APIs using commands 8000h-FFFFh. Microsoft reserves commands 0000h-7FFFh for future expansion of the standard fast disk device API.
When sending the BD_SC_Get_Version command, the client must set the AX register to the value BD_SC_Get_Version, and the EDI register must contain a pointer to the Block Device Descriptor. When exiting, the fast disk device clears the carry flag, sets the AH register to the fast disk device major version number, and sets the AL register to the fast disk device minor version number.
When returning, the carry flag is always used to indicate an error. In case of an error, the error number will be returned in AX. All synchronous commands that are not recognized by a fast disk device should return with the carry flag set, and the register AX= should contain the BD_SC_Err_Invalid_Cmd value.
The virtual block device does one of two things depending upon the BDF_Serial_Cmd flag in the fast disk device's BDD. If the flag is clear, the fast disk device's command procedure is called with the original client command chain. In this case, the virtual block device will do no error checking or processing of the command list in any way.
For serial commands, the virtual block device processes the entire command chain before sending the commands to the fast disk device. In this case, the virtual block device queues commands so that high priority commands will be processed ahead of all low priority commands regardless of the client that submitted them. It will also check for invalid sector ranges, and any invalid command blocks will be completed without the fast disk device ever seeing them. If a command is canceled that is in the command queue, the virtual block device will cancel without sending the command to the fast disk device. Commands will be sent to the fast disk device one at a time. When the fast disk device calls BlockDev_Command_Complete for the current command, the virtual block device will immediately submit the next command in the queue if any are pending.