GDLC Special Kernel Services

Edit online

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 DLC at the time of execution. This process 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.

Note: A function handler must never call another DLC entry directly. Direct calls made under lock cause a fatal sleep. The only exception to this rule is when 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 an error code (EAGAIN 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 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:

Item Description
user-terminated busy mode (I-frame only) 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.
timer-terminated busy mode (all frame types) If the kernel user cannot handle a particular receive packet and wants DLC to hold the receive buffer for a short period and then recall the user's receive function, a DLC_FUNC_RETRY return code is sent 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; when the timer expires, the receive-data functional entry is called again.