On 04/13/2012 04:09 AM, Peter Maydell wrote:
On 13 April 2012 09:33, Paolo Bonzini<pbonz...@redhat.com> wrote:
Il 13/04/2012 10:12, Peter Maydell ha scritto:
Half a dozen from random grep:
"xilinx,timer" -- memory region size depends on a property
"lan9118" -- which MemoryRegionOps we use for the region depends
on the "mode_16bit" property.
You can set these at realize time, before the memory region itself is
realized (realization uses pre-order for this reason).
"SUNW,tcx" -- number of memory regions depend on depth property
The regions can still exist in the device, whether they're mapped
depends on the depth property.
This is like saying that you should still have 512 IRQ lines on
every IRQ array,
There's a fairly nasty dependency problem here. Let's say that we did:
[device "pic"]
irq_num = 16
irq[0] = /mydevice/irq
irq[1] = /foodev/irq
irq[2] = /bardev/irq
irq[16] = /baz/irq # should throw an error
This is clearly something we want to be able to express. The trouble is that
since the irq_num property affects whether irq[16] is valid, you would need to
have a multi-stage construction process or have a strict property assignment
ordering that was preserved in the config file. Since we're dealing with a
graph, relying on ordering will probably never actually work.
There are alternative ways to handle this. We could make use of Paolo's
"default property" hook and then at realize time, validate that we don't have
irq's assigned that violate irq_num. This still gives you the nice end user
error without requiring crazy dependency mapping.
The downside is that if you introspect the properties, you'll get a single
generic irq[*] or something before realize. But since this is a relatively
uncommon requirement, I think it's a reasonable compromise.
Regards,
Anthony Liguori
