Driver Framework

Driver Framework

JNode's Device Manager and Driver framework abstracts hardware into object-oriented APIs, managing the lifecycle of devices and their drivers.

Overview

In JNode, hardware control is strictly organized. Devices are represented by Device objects, and their controlling logic is encapsulated in Driver objects. The DeviceManager oversees the registration and lifecycle of these components.

Because JNode is a single-address-space OS, drivers run in the same memory space as the rest of the kernel and user applications, enabling extremely fast, zero-copy I/O.

Core Concepts

Location: core/src/driver/org/jnode/driver/

1. DeviceManager (AbstractDeviceManager, DefaultDeviceManager)

The central registry (core/src/driver/org/jnode/driver/DeviceManager.java). It keeps track of all known Buses and Devices, and provides:

• Device Tree: The getDevices() method returns all registered devices; getSystemBus() returns the root bus (a Bus is itself a device with children)
• Driver Registration: register(Device) automatically finds a suitable driver via DeviceToDriverMapper extensions and binds it
• API Query: getDevicesByAPI(Class<? extends DeviceAPI>) finds all devices implementing a specific API

The DefaultDeviceManager loads DeviceFinder and DeviceToDriverMapper extensions from plugin descriptors at startup.

2. Bus

A hardware bus (e.g., PCI, USB, IDE). A bus is a special kind of device that can have child devices connected to it. DeviceFinders run on buses to probe for attached hardware.

3. Device

A software representation of a hardware endpoint (e.g., a specific network card or a hard drive).

• Maintains a reference to its parent Bus.
• Can have exactly one Driver assigned to it.
• Exposes functionality through Device APIs.

4. Driver

The code that controls a device.

• Must extend the abstract Driver class.
• Implements startDevice() and stopDevice().
• Usually registers one or more DeviceAPI implementations with its assigned Device.

5. DeviceAPI Pattern

All device APIs extend the marker interface DeviceAPI (org.jnode.driver.DeviceAPI). Each device can register multiple API implementations:

• registerAPI(Class<T>, T) — Registers an API implementation on a device
• implementsAPI(Class) — Checks if device supports an API
• getAPI(Class) — Retrieves the API instance (throws ApiNotFoundException if not present)

Common API hierarchies:

• BlockDeviceAPI → FSBlockDeviceAPI (filesystems)
• CharacterDeviceAPI → SerialPortAPI
• NetDeviceAPI (network)
• KeyboardAPI, PointerAPI (input)
• FrameBufferAPI (video)

// Example: Using a Device API
Device dev = deviceManager.getDevice("hda1");
BlockDeviceAPI api = dev.getAPI(BlockDeviceAPI.class);
api.read(0, buffer);

How Drivers Are Matched to Devices

JNode uses the Plugin System's Extension Points to match drivers to devices dynamically.

1. The Bus Plugin Defines an Extension Point: E.g., The PCI bus plugin declares org.jnode.driver.bus.pci.device-factories.
2. Driver Plugins Contribute Extensions: A VGA driver plugin contributes to that extension point, specifying the PCI Vendor ID and Device ID it supports, along with the name of its Driver class.
3. Discovery: When the DeviceManager probes the PCI bus and finds a card with that Vendor/Device ID, it looks up the extension registry, instantiates the corresponding Driver class, and binds it to the newly created Device.

Subsystems

The driver framework contains standard APIs for various hardware types:

Package	Purpose
org.jnode.driver.bus	Bus definitions (PCI, USB, PCMCIA, SMBus) — see Bus-Drivers
org.jnode.driver.character	Character devices
org.jnode.driver.console	Text and graphical console abstraction
org.jnode.driver.input	Keyboards, mice, pointer devices — see Input-Drivers
org.jnode.driver.serial	Serial ports (COM1, etc.)
org.jnode.driver.video	Video cards and framebuffers
org.jnode.driver.block	Found in fs/src/driver/ - Block devices (HDDs)
org.jnode.driver.net	Found in net/src/driver/ - Network interfaces

Hardware Resources

Drivers must coordinate access to hardware resources to prevent conflicts. See Resource-Management for detailed documentation.

• ResourceManager
• IOResource (Ports)
• MemoryResource (Memory-Mapped I/O)
• IRQResource (Interrupts)
• DMAResource (Direct Memory Access)

Drivers claim these resources during startDevice() and release them during stopDevice().

ResourceManager rm = InitialNaming.lookup(ResourceManager.NAME);
IOResource io = rm.claimIOResource(owner, startPort, length);

Event System

Listener interfaces for observing device events:

• DeviceManagerListener — DeviceManagerListener — Notified when a device is registered or unregistered in the manager. Used for deferred initialization (e.g., waiting for a framebuffer device to appear).
• DeviceListener — DeviceListener — Notified when a device's driver starts or stops.

Related Pages

• Plugin-System — How drivers are loaded and registered via descriptors.
• Memory-Management — How drivers access memory via MemoryResource.
• Code-Conventions — Conventions for managing resources (always try...finally).
• DriverPermission — Security permission class for driver resource access.