Re: [Qemu-devel] [RFC] Machine description as data

[Mitch Bradley <wmb@firmworks.com>]

>
> We want a machine configuration: a tree describing configurable devices
> and their configurable properties.
>   


Regarding configurable devices in Open Firmware:

The baseline usage model for configurable devices was that the firmware 
is responsible for establishing a consistent system configuration, 
possibly based on user-modifiable variables in non-volatile storage.  It 
reports the actual configuration to the OS via the device tree.

For cases where the choice needs to deferred until later, or perhaps 
changed dynamically, a device tree property reports the set of 
possibilities.  In cases where the firmware has already set up the 
devices, it reports the current choice via another property.

The device tree hierarchy serves as the "name space" framework for these 
properties.  Obviously, you need to specify the device for which the 
choice set applies.  The device tree is a coherent naming model for that 
purpose.

Obviously the hierarchical model has problems for highly-configurable 
chipsets in which a setting can result in a wholesale rearrangement of 
the overall connectivity, but it seems to me that board-design 
constraints usually make that a non-problem. The wiring on a given board 
generally forces the choice at that level, so the firmware for that 
board need not report that as a configurable choice.
> For PowerPC, we also want a machine description: a tree describing those
> devices and properties that the kernel can't easily and safely probe.
>   

The gist of the above sentence seems to presuppose that, if the kernel 
can probe, it should.  That's not the only way of thinking about the 
problem.  As a practical matter, the firmware usually needs to do a fair 
amount of probing too, in order to locate the console display and the 
boot devices.  In the process, the firmware usually discovers pretty 
much the entire machine configuration.  If the OS has to repeat the 
process from scratch, it slows down the boot process.  So the IEEE1275 
design supports the model where the firmware can do all the probing, 
handing off a complete system description to the OS.  The OS startup 
code can walk the tree and attach device drivers for what it finds, then 
arrange to handle insert/remove events from hot-pluggable buses.