DeviceFinder

DeviceFinder

Discovery mechanism for finding devices on buses during system startup.

Overview

The DeviceFinder interface (core/src/driver/org/jnode/driver/DeviceFinder.java) defines the contract for hardware discovery on a given bus. It is a key component in JNode's plugin-based device discovery system, working in conjunction with the DeviceManager and DeviceFinderPlugin to enumerate all hardware during boot.

When the DeviceFinderPlugin starts during the plugin initialization phase, it triggers DeviceManager.findDevices(), which iterates over all registered DeviceFinder implementations to scan each bus for discoverable hardware.

Key Components

Class / File	Role
core/src/driver/org/jnode/driver/DeviceFinder.java	Public interface defining the findDevices(DeviceManager, Bus) method
core/src/driver/org/jnode/driver/DeviceFinderPlugin.java	Plugin that initiates the device discovery process at boot
core/src/driver/org/jnode/driver/bus/pci/PCIFinder.java	PCI bus implementation that probes PCI configuration space
core/src/driver/org/jnode/driver/serial/SerialPortFinder.java	ISA/IO space probe for standard COM ports
core/src/driver/org/jnode/driver/system/firmware/bios/BiosFinder.java	BIOS firmware device discovery
gui/src/driver/org/jnode/driver/video/vga/VGAFinder.java	VGA graphics device detection
gui/src/driver/org/jnode/driver/ps2/PS2Finder.java	PS/2 keyboard and mouse port enumeration
gui/src/driver/org/jnode/driver/sound/speaker/pc/PCSpeakerFinder.java	PC speaker device detection
fs/src/driver/org/jnode/driver/block/floppy/FloppyControllerFinder.java	Floppy disk controller discovery
net/src/driver/org/jnode/driver/net/loopback/LoopbackFinder.java	Virtual loopback network device

How It Works

Plugin Startup Sequence

At boot, the DeviceFinderPlugin is started as part of the plugin lifecycle:

// DeviceFinderPlugin.startPlugin()
protected void startPlugin() throws PluginException {
    final DefaultDeviceManager devMan = (DefaultDeviceManager) 
        InitialNaming.lookup(DeviceManager.NAME);
    devMan.findDevices();
}

Discovery Process

DefaultDeviceManager.findDevices() iterates through all registered DeviceFinder implementations:

// DefaultDeviceManager.findDevices()
public final void findDevices() throws DeviceException, InterruptedException {
    for (DeviceFinder finder : finders) {
        finder.findDevices(this, getSystemBus());
    }
}

Each DeviceFinder implementation:

1. Receives the DeviceManager instance and the system bus
2. Traverses its specific bus (PCI, ISA, etc.)
3. Creates Device objects for discovered hardware
4. Registers them with the DeviceManager via registerDevice()

Registration via Extension Points

DeviceFinder implementations are loaded as plugin extensions from the org.jnode.driver.finders extension point:

<extension point="org.jnode.driver.finders">
  <finder class="org.jnode.driver.bus.pci.PCIFinder"/>
  <finder class="org.jnode.driver.serial.SerialPortFinder"/>
</extension>

The DefaultDeviceManager.loadFinders() method loads all registered finders during initialization.

PCI Finder Example

The PCIFinder demonstrates a complex implementation:

// PCIFinder.findDevices()
public void findDevices(DeviceManager devMan, Bus bus) throws DeviceException {
    PCIBus pciBus = (PCIBus) bus;
    for (int busNumber = 0; busNumber < MAX_BUSES; busNumber++) {
        for (int deviceNumber = 0; deviceNumber < 32; deviceNumber++) {
            for (int functionNumber = 0; functionNumber < 8; functionNumber++) {
                PCIAddress address = new PCIAddress(busNumber, deviceNumber, functionNumber);
                if (pciBus.isDevicePresent(address)) {
                    PCIDevice device = new PCIDevice(pciBus, address);
                    devMan.registerDevice(device);
                }
            }
        }
    }
}

Integration with Driver Binding

After DeviceFinder registers a device, the DeviceManager immediately attempts to bind a driver:

1. Device registration — DeviceFinder creates and registers a device
2. Driver matching — DeviceManager.findDriver() iterates through registered DeviceToDriverMapper implementations
3. Mapper selection — Mappers are tried in priority order (predefined → device+revision → device ID → device class)
4. Driver binding — The first mapper that returns a non-null driver wins

This separation allows finders to be generic (enumerating hardware) while mappers provide specific driver matching logic.

Gotchas

• Finder ordering matters — Finders are tried in registration order; ensure the system bus is fully populated before finders that depend on child buses run
• Bus hierarchy — Some finders (e.g., PCI) attach child buses to the system bus; subsequent finders may discover devices on these child buses
• Deferred initialization — Some devices may need listeners to trigger driver binding after all finders have completed (use DeviceManagerListener)
• Discovery failures — Individual finder failures are typically logged but don't halt the overall discovery process

Related Pages

• DeviceManager — Central registry that coordinates finders and mappers
• DeviceToDriverMapper — Strategy pattern for matching devices to drivers
• Driver-Framework — Overall driver architecture
• Bus-Drivers — Bus-specific drivers (PCI, USB, etc.)
• Plugin-System — Extension point mechanism for finders and mappers
• DeviceFinderPlugin — Bootstrap plugin that initiates discovery