Generic data link control (GDLC) provides special services for a kernel user. However, a trusted environment must exist within the kernel. Instead of the DLC device manager copying asynchronous event data into user space, the kernel user must specify function pointers to special routines called function handlers. Function handlers are called by the DLC at the time of execution. This allows maximum performance between the kernel user and the DLC layers. Each kernel user is required to restrict the number of function handlers to a minimum path length and use the communications memory buffer (mbuf) scheme.
A function handler must never call another DLC entry directly. This is because direct calls are made under lock, causing a fatal sleep. The only exception to this rule is that a kernel user may call the dlcwritex entry point during its service of any of the four receive data functions. Calling the dlcwritex entry point allows immediate responses to be generated without an intermediate task switch. Special logic is required within the DLC device manager to check the process identification of the user calling a write operation. If it is a DLC process and the internal queuing capability of the DLC has been exceeded, the write is sent back with a bad return code (EAGAIN return value) instead of putting the calling process (DLC) to sleep. It is then up to the calling user subroutine to return a special notification to the DLC from its receive data function to ensure a retry of the receive buffer at a later time.
The user-provided function handlers are:
| Datagram Data Received Routine | Called any time a datagram packet is received for the kernel user. |
| Exception Condition Routine | Called any time an asynchronous event occurs that must notify the kernel user, such as SAP Closed or Station Contacted. |
| I-Frame Data Received Routine | Called each time a normal sequenced data packet is received for the kernel user. |
| Network Data Received Routine | Called any time network-specific data is received for the kernel user. |
| XID Data Received Routine | Called any time an exchange identification (XID) packet is received for the kernel user. |
The dlcread and dlcselect entry points for DLC are not called by the kernel user because the asynchronous functional entries are called directly by the DLC device manager. Generally, any queuing of these events must occur in the user's function handler. If, however, the kernel user cannot handle a particular receive packet, the DLC device manager may hold the last receive buffer and enter one of two special user-busy modes:
If the kernel user cannot handle a received I-frame (due to problems such as queue blockage), a DLC_FUNC_BUSY return code is given back, and DLC holds the buffer pointer and enters local-busy mode to stop the remote station's I-frame transmissions. The kernel user must call the Exit Local Busy function to reset local-busy mode and start the reception of I-frames again. Only normal sequenced I-frames can be stopped. XID, datagram, and network data are not affected by local-busy mode.
If the kernel user cannot handle a particular receive packet and wants DLC to hold the receive buffer for a short period and then re-call the user's receive function, a DLC_FUNC_RETRY return code is given back to DLC. If the receive packet is a sequenced I-frame, the station enters local-busy mode for that period. In all cases, a timer is started; once the timer expires, the receive data functional entry is called again.