UDI Channels

A UDI "channel" is the nomenclature used in the UDI specification for an IPC (Inter Process Communication) link between two driver end-points. In other words, it is an abstraction of IPC on the host kernel which implements a compliant UDI Environment. The specific underlying mechanics of a particular kernel's implementation of UDI channel IPC, and how messages are sent across these channels are left up to the implementor.

What is a UDI Channel?

UDI channels are generally two-way communication links, with the exception of the channel formed between the kernel and the driver for the UDI Management Metalanguage Channel. Every other channel is a two-way communication link. The Management Metalanguage channel is two-way as well technically, but there is a constraint applied by the specification which states that drivers cannot initiate communications with the host kernel unless first asked to do so. The kernel can "post" requests to the driver on this channel if it is interested in communicating with the driver, and the driver can "hold on" to them until it has an appropriate response. An example would be hotplug device enumeration, where if the kernel is interested, it can "post" a request for the driver to "hold on to", and the driver will not respond until a hotplug event has occured. If the kernel did not "post" the request to indicate that it was interested in hotplug events, the driver cannot initiate a hotplug notification on its own.

The management metalanguage channel is the only channel with such a restriction.

Underlying implementation details

The specific underlying behaviour of IPC messaging "channels" is implementation defined. For a Separate Address Space Driver kernel, "channels" may be implemented as cross-process IPC using shared memory or message passing. For a purely monolithic kernel, or a Single Address Space kernel, "channels" can be simplified to nothing more than function calls. UDI does not impose any particular kernel design or driver environment design on kernels -- kernels are free to flexibly implement the interfaces in the UDI specification in a manner that suits them best, and it fastest and best optimized for their own situation, workload and requirements.

Interfaces and structures

Key structures

/* The opaque type used to refer to a channel. Channels are refered to via opaque handles,
 * and the underlying kernel implementation is hidden from drivers.
 */
typedef <HANDLE> udi_channel_t;

/* The core IPC message type used by UDI. Every IPC message contains
 * this base type, and new message types can be created by extending
 * this type. Every UDI IPC message (aka "control block") is based
 * on this type, the udi_cb_t structure.
 */
typedef struct {
	udi_channel_t channel;
	void *context;
	void *scratch;
	void *initiator_context;
	udi_origin_t origin;
} udi_cb_t;

Key service calls

/* Used to spawn new channels. */
void udi_channel_spawn(
	udi_channel_spawn_call_t *callback,
	udi_cb_t *gcb,
	udi_channel_t channel, 
	udi_index_t spawn_idx,
	udi_index_t ops_idx,
	void *channel_context);

/* Used to destroy currently active channels. */
void udi_channel_close(udi_channel_t channel);