1. OVERVIEW

This document defines the process used by the kernel to load SDI drivers into memory and prepare them for execution.

It describes how driver binaries are mapped, relocated, and initialized so they can interact with the SDI kernel interface.

The loading process is flexible and implementation-defined, but this document provides a reference model and recommended behavior for consistency across systems.

SDI uses the normative language defined by BCP 14 (RFC 2119 and RFC 8174). In this document, the terms MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, and OPTIONAL are to be interpreted as defined by BCP 14.

  1. SDI Driver Loading

A kernel MUST implement the SDI reference loading model described below, the kernel MUST follow all requirements in steps 1–6. The SDI reference loading model is defined as follows:

  1. Acquisition: The kernel obtains a driver binary from any supported source (ramdisk, EFI partition, anywhere).

  2. Validation: The driver MUST be verified as a valid ELF module for the target architecture.

  3. Memory mapping: The driver MUST be mapped into a contiguous virtual address range with correct segment permissions.

  4. Relocation: Any required relocations MUST be resolved before execution.

  5. Initialization: The driver entry point MUST be invoked with a valid SDI kernel API structure and the driver information structure as arguments.

  6. Registration: The driver SHOULD expose its metadata and class-defined interface to the kernel after successful initialization.

  7. Arguments for the driver

Drivers are given two arguments as their input, the first input MUST be the sdi_ops structure. The second input MUST be the sdi_driver_info structure. Both MUST be allocated by the kernel.

The sdi_ops structure MUST be filled out by the kernel, any functions not implemented MUST be NULL, the UID MUST be filled out and CANNOT be reused. The sdi_driver_info MUST be zeroed, the driver MUST fill out the structure.

An example function prototype for the driver might look like sdi_status entry(struct sdi_ops* ops, struct sdi_driver_info* drv_info); which is what is required. As you can see it takes in the ops and drv_info, and it returns an sdi_status type.

  1. sdi_ops and function availability

The kernel MUST populate the sdi_ops structure before passing it to the driver. If a function is not supported by the kernel or underlying architecture, its function pointer MUST be set to NULL. The log function MUST be provided by the kernel. It MAY be implemented as a stub that performs no operation, but it MUST NOT be NULL and MUST point to a valid function. Drivers MAY call the log function at any time without checking for NULL.