[cdi-devel] Proposed Dynamic Driver Loading System

[Matthew Iselin <matthew@xxxxxxxxxxxxxx>]

Hi,

I have been able to get access to a WiFi hotspot, so this mail comes a
little earlier than I thought it would. :)

This proposal covers the addition of a feature to CDI which enables drivers
to be loaded dynamically and on-demand rather than statically at a single
point in time.

Now that drivers no longer do their own probe of devices, but rather provide
a set of initialisation functions to the OS which are called at a convenient
time by the OS, it is possible to implement an (optional) scheme through
which drivers can be loaded on-demand. The benefits of this include reducing
the memory footprint for the OS (especially in the case of monolithic OS's)
and greater flexibility.

The idea is that the OS stores a map of device identifiers (at this stage the
proposal considers the use of PCI vendor and device codes) which detail the
name of a driver which is to be loaded if the given device is detected. This
list may be OS-specific, or there may be a generic list provided as part of
CDI. Either way, the OS is open to interpret the driver name as it sees fit:
for example, appending ".o" in the case of Pedigree.

This map might look something like this:

/** OS-specific map of PCI identifiers -> driver names */

struct cdi_os_pci_driver_map = {
    0x8086, 0x1230, "piix", // Vendor, Device, Driver name
    ...
};

I would like for this map to be implemented as part of CDI, in order to ensure
that the list is kept up-to-date with drivers as they are written for CDI.
Keeping the list in CDI also decreases the amount of work required to port CDI
to a new OS and take advantage of these kind of features.

In this early draft of the concept, there is no support for non-PCI devices.
Things such as USB with each device having a class code (eg, mass storage, or
human interface device) may need their own list. This would be logical as the
method for loading drivers dynamically upon a hotplug or similar event could
be quite different to that of detecting static PCI devices at boot-time. Hot
plug PCI devices are considered to be out of the scope of this proposal.

At a time defined by the OS implementing CDI, the list of PCI devices will be
iterated, and each device will be checked against the known PCI->driver list.
Should a driver be found in this list, the driver will be loaded (if not
already) and used to initialise the detected device.

Now, this brings up a small tangent: it is my belief that driver loading could
be added to the CDI interface, as something like:

/* Returns -1 if the driver could not be loaded, zero otherwise */
int cdi_load_driver(const char *);

However, this may be difficult to justify. After all, how many actual drivers
really need to load another driver? The alternative is to have the OS perform
driver loading itself, which effectively moves most of this subsystem to the
OS side (making this hardly related to CDI at all :) )

So the routine at boot-time might be something like this, for a monolithic
kernel:
1. Probe the PCI bus and develop a list of devices that are present
2. Use this list to find drivers to load based on the PCI->driver map
3. Load each driver, calling the necessary initialisation function for each
   relevant device.
4. (optional) Install hooks for hotplugging

Point 4 may need explanation. The kernel will need to provide some form of
callback to be called when a new device becomes available (eg, a USB device
is plugged in). Whilst non-PCI devices are out of the scope of this initial
proposal, it cannot hurt to look into the crystal ball and add support for
future expansion.

This proposal covers the concept of adding a dynamic driver loading system to
CDI in order to reduce memory footprint, improve loading times of OS's
utilising CDI, and to also establish initial steps towards supporting proper
hotplugging of more complex devices. The proposal can be interpreted as being
completely unrelated to CDI; this is only true if features such as
`cdi_load_driver' are removed and the PCI->device map is not kept within CDI.

As an aside, this might also be a good time to mention that it might be nice
to start a wiki or something somewhere to document CDI, how to port CDI to a
new OS, and some of the optional features like the one proposed here.

Cheers,

Matt