Currently drivers that use new driver API and device manager do not have
proper mechanism of quick selection of compatible hardware. Current
approach is based on driver searching in sub-directories defined by hard
coded PCI categories [1]. This approach of course will not properly work
for non PCI bus such as ACPI and FDT and cause probing too much drivers.
Experimentally confirmed that driver loading and probing takes
significant time for boot in a virtual machine and deleting unneeded
drivers reduce kernel startup time by multiple times.
I suggest to introduce compatible hardware definition format that will
be stored in resources of new driver API driver add-ons so compatible
driver can be quickly searched without actually loading unneeded driver
add-ons. Addressed problem is tracked in ticket #18333 [2].
Proposed boot sequence with using compatible hardware definitions.
1. haiku_loader load resources of boot add-ons in addition to code and data.
2. Kernel collects compatible hardware definitions of all boot drivers
to central compatible drivers registry. Compatible driver registry can
be indexed and cached if needed.
3. When deciding which driver to use for specific device_node, the
device manager will query device_node attributes in central compatible
drivers registry and get a list of matched compatible driver module
names sorted by score descending. Compatible driver lookup use only
device_node attribute matching, so it is generic and do not depend of
specific hardware type and used bus.
4. When boot volume is mounted, resources of driver add-ons will be
loaded into central compatible drivers registry and device manager will
be notified to lookup for drivers if some devices have not yet driver
attached.
5. Node monitor in driver add-ons directory will be used to update
central compatible drivers registry at runtime. It will allow to install
new drivers without reboot.
Compatible hardware definition format.
Format is based on KMessage and stored in driver add-on resources under
"driver" name. Message have following attributes.
string "module": Module name that will be used by device manager for
matched devices.
float "score": If multiple drivers will be matched for the same device,
drivers will be probed in descending order of this field.
message "attrs": Attributes to be matched for device_node. All
attributes specified in "attrs" should be present in device_node and its
values should be equal to device_node ones. device_node attributes that
are not present in "attrs" are ignored and not use for matching. Empty
"attrs" will match everything. "attrs" may contains attributes with
duplicate name, in this case any of attribute value of the same name can
be matched.
message "info": Arbitrary data that is passed to driver. It can contain
device-specific configuration information and quirks.
string "name": User friendly name of device. It is intended for cases
where multiple device types are handled by the same driver and it is
desired to display per-device name to user.
array of message "driver": Nested driver definition nodes. It have the
same format as root node. If this property is used, only leaf nodes will
be used for matching and leaf nodes will inherit all parent nodes
properties. This property is used to reduce duplication of definitions.
For example if there are multiple attribute definitions for the same
bus, "device/bus" attribute can be stored in parent node and be applied
to all child nodes.
Examples of driver hardware definitions can be found in ticket
attachments [2].
Benefits of using driver definitions:
1. Load only needed driver add-ons ad reduce boot time.
2. Remove hard coding on PCI bus and allow to install new drivers
without modifying kernel code. Ability to make 3rd-party drivers for new
devices and busses.
3. No need of per-bus registration and handling code. The device manager
device_node system with "device/bus" node can handle any and lookup
compatible drivers in generic way.
4. One place and common generic format of compatible hardware
definitions. No need to search for specific driver source code and
driver-specific format for compatible hardware definitions. Possibility
to add new compatible hardware IDs for driver.
5. Possibility of creating online web search for compatible Haiku
hardware based on driver add-ons compatible hardware information.
1.
https://git.haiku-os.org/haiku/tree/src/system/kernel/device_manager/device_manager.cpp?id=b6356b9116f2238d880e558637200cde1cd7e407#n1633
2. https://dev.haiku-os.org/ticket/18333
