next up previous
Next: Conclusion Up: Multiple Passes of the Previous: Multiple-Pass Proposal

Subsections

Tricky Problems Revisited

On its own multiple passes of the device tree does not solve any problems. However, it does provide a framework that can be used to solve the problems described earlier. A possible solution to each problem using multiple passes is outlined below.

Low-level Hardware

Of the problems listed, drivers for low-level hardware is probably the simplest to solve. With the multiple pass framework, the software to manage these devices can move from platform-specific start-up code into platform-specific early drivers. For example, interrupt controllers on x86 platforms can probe as ``new-bus'' devices that properly reserve all their associated resources.

In the case of the ACPI bus driver, the hack to order specific devices based on device IDs can be removed. Instead, the drivers for the various ``special'' devices can become early drivers. The pass levels of these drivers can be used to guarantee ordering.

Resource Discovery and Management

In the previous discussion of resource discovery and management, a solution for PCI bus hierarchies was proposed. This solution was to walk the device tree allocating resources as necessary before attaching drivers. One of the complications with this is that this requires recursing into buses behind PCI-PCI bridges and maintaining state for each bus, etc. This can be accomplished more easily if each PCI-PCI bridge and PCI bus are managed by a device driver when this process is performed. In that case, each driver is only responsible for managing its own state.

A way to achieve this using early drivers is to allow PCI bridge and bus drivers to probe as BUS_PASS_BUS devices which enumerate all child devices during the initial attach. However, resources would not be allocated to child devices until a later point such as after the BUS_PASS_RESOURCE pass has completed. PCI bus drivers would provide methods to enumerate the range of resources required for child devices. The implementation of this method would include special handling for PCI-PCI bridges that called down into the child PCI bus to determine its resource requirements and use that to program the decoding windows on the parent side of the PCI-PCI bridge.

Boot vs Non-boot Device Probing

One of the largest differences between boot and non-boot device probing is the lack of thread scheduling during boot. One of the things the thread scheduler requires to run are working timers to support sleep timeouts. Changing the drivers for timer devices to be early devices that probe as BUS_PASS_TIMER would allow these devices to probe before most other drivers. After the BUS_PASS_SCHEDULER pass, the thread scheduler could be started. All drivers probed after that would then probe in an environment similar to the post-boot environment.


next up previous
Next: Conclusion Up: Multiple Passes of the Previous: Multiple-Pass Proposal