1. PURPOSE

The Simple Driver Interface (SDI) defines a portable and minimal contract between operating systems and hardware drivers.

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.

SDI is designed to:

• standardize driver interaction across different kernels
• reduce duplication of driver development
• provide a consistent hardware abstraction layer (HAL)
• enable cross system driver reuse

SDI does not define a full operating system model.
SDI does not define scheduling, user space, or system policy.

SDI only defines how drivers interact with a kernel.

2. SCOPE

SDI covers the following areas:

• hardware discovery and access
• memory mapping required for device operation
• interrupt and event delivery to drivers
• device I/O operations
• optional subsystem interfaces (graphics, network, storage, etc)

SDI does not cover:

• process scheduling
• filesystem design
• user space interfaces
• security policy enforcement
• application level APIs

3. DESIGN GOALS

SDI v1.0 is built on the following principles:

• minimal required kernel interface
• single threaded driver execution model
  • this model MAY be revised in future versions
  • v1.0 drivers MUST NOT assume multi-threaded execution
  • v1.0 drivers SHOULD implement internal thread-safety
• explicit versioning for all interfaces
• capability based feature discovery
• strict separation between required and optional features
• deterministic driver behavior across implementations

4. DRIVER MODEL

All SDI drivers MUST follow a function pointer based interface.

Drivers:

• MUST NOT manage threads
• MUST NOT allocate system memory directly without kernel request
• MUST NOT access hardware directly outside SDI provided functions
• MUST operate only through defined kernel provided functions

5. HAL REQUIREMENTS

Every SDI compliant kernel MUST provide a minimal HAL compliant with the sdi_ops structure defined in defines.h.

6. VERSIONING MODEL

SDI uses semantic versioning:

• major version changes indicate breaking interface changes or new required categories
• minor version changes indicate additions within existing categories
• patch version changes indicate bug fixes or clarifications

Drivers MUST declare supported SDI versions.

Kernels MUST expose supported SDI versions.

7. CAPABILITY DISCOVERY

Kernels expose supported features through a capability table.

Drivers MUST check capabilities before using optional features.

If a feature is not present, drivers MUST fallback to defined behavior.

8. IMPLEMENTATION NOTE

This document defines behavior only.

Reference implementations exist for validation purposes.

If behavior is unclear, it is considered undefined until specified in a future SDI version.