Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()

[Anthony Liguori]

On 04/13/2012 04:09 AM, Peter Maydell wrote:
> On 13 April 2012 09:33, Paolo Bonzini<address@hidden>  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