On Fri, Apr 13, 2012 at 09:32, Paolo Bonzini wrote:
> Il 13/04/2012 11:09, Peter Maydell ha scritto:
>> On 13 April 2012 09:33, Paolo Bonzini 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 proper
On 04/13/2012 09:21 AM, Andreas Färber wrote:
Am 13.04.2012 16:08, schrieb Paolo Bonzini:
Il 13/04/2012 16:06, Andreas Färber ha scritto:
I'm still talking about the (pretty clear to me) graph that I posted.
There, object A's init function creates a new qdev object - . Creating
an object can fa
On 04/13/2012 09:06 AM, Andreas Färber wrote:
Am 13.04.2012 16:00, schrieb Anthony Liguori:
On 04/13/2012 08:36 AM, Andreas Färber wrote:
Am 13.04.2012 09:17, schrieb Paolo Bonzini:
initfn is unable to handle errors btw, which is another reason to do
object creations in a second-stage construc
Am 13.04.2012 16:25, schrieb Paolo Bonzini:
> Il 13/04/2012 16:21, Andreas Färber ha scritto:
>> Am 13.04.2012 16:08, schrieb Paolo Bonzini:
>>> Il 13/04/2012 16:06, Andreas Färber ha scritto:
I'm still talking about the (pretty clear to me) graph that I posted.
There, object A's init fun
Il 13/04/2012 16:21, Andreas Färber ha scritto:
> Am 13.04.2012 16:08, schrieb Paolo Bonzini:
>> Il 13/04/2012 16:06, Andreas Färber ha scritto:
>>> I'm still talking about the (pretty clear to me) graph that I posted.
>>> There, object A's init function creates a new qdev object - . Creating
>>> a
Am 13.04.2012 16:08, schrieb Paolo Bonzini:
> Il 13/04/2012 16:06, Andreas Färber ha scritto:
>> I'm still talking about the (pretty clear to me) graph that I posted.
>> There, object A's init function creates a new qdev object - . Creating
>> an object can fail - fatally or non-fatally.
>>
>> And
Il 13/04/2012 16:06, Andreas Färber ha scritto:
> I'm still talking about the (pretty clear to me) graph that I posted.
> There, object A's init function creates a new qdev object - . Creating
> an object can fail - fatally or non-fatally.
>
> And yes, exactly my point, currently initfn (first sta
Am 13.04.2012 16:00, schrieb Anthony Liguori:
> On 04/13/2012 08:36 AM, Andreas Färber wrote:
>> Am 13.04.2012 09:17, schrieb Paolo Bonzini:
initfn is unable to handle errors btw, which is another reason to do
object creations in a second-stage constructor.
>>>
>>> What error handling do
On 04/13/2012 08:36 AM, Andreas Färber wrote:
Am 13.04.2012 09:17, schrieb Paolo Bonzini:
initfn is unable to handle errors btw, which is another reason to do
object creations in a second-stage constructor.
What error handling do you need specifically? You could add an Error **
argument to ob
Am 13.04.2012 09:17, schrieb Paolo Bonzini:
>> initfn is unable to handle errors btw, which is another reason to do
>> object creations in a second-stage constructor.
>
> What error handling do you need specifically? You could add an Error **
> argument to object_{new,initialize{,_with_type} too
On 04/13/2012 04:09 AM, Peter Maydell wrote:
On 13 April 2012 09:33, Paolo Bonzini 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
Il 13/04/2012 12:43, Peter Maydell ha scritto:
> On 13 April 2012 11:24, Paolo Bonzini wrote:
>> The PC has a similar model but it is implemented with N+1 devices, one
>> APIC per CPU plus the IO-APIC.
>>
>> For the ARM, it seems cleaner to me to also split it into a per-CPU
>> object (gic_cpu_ops
On 13 April 2012 11:24, Paolo Bonzini wrote:
> The PC has a similar model but it is implemented with N+1 devices, one
> APIC per CPU plus the IO-APIC.
>
> For the ARM, it seems cleaner to me to also split it into a per-CPU
> object (gic_cpu_ops) and a connection object (gic_dist_ops +
> gic_thiscp
Il 13/04/2012 12:09, Peter Maydell ha scritto:
>> The GIC can have a (strongly-typed) backlink to the SoC, and can call
>> object_property_get on it.
>
> The trouble with this is that the GIC is embedded into about
> half a dozen different parent devices, all of which obviously
> have different ty
On 13 April 2012 11:00, Paolo Bonzini wrote:
> Il 13/04/2012 11:53, Peter Maydell ha scritto:
>> On 13 April 2012 10:32, Paolo Bonzini wrote:
>>> Il 13/04/2012 11:09, Peter Maydell ha scritto:
You're right in general that we should be modelling these as
container objects (I posted a ser
Il 13/04/2012 11:53, Peter Maydell ha scritto:
> On 13 April 2012 10:32, Paolo Bonzini wrote:
>> Il 13/04/2012 11:09, Peter Maydell ha scritto:
>>> You're right in general that we should be modelling these as
>>> container objects (I posted a series the other week that starts
>>> to move in that d
On 13 April 2012 10:32, Paolo Bonzini wrote:
> Il 13/04/2012 11:09, Peter Maydell ha scritto:
>> You're right in general that we should be modelling these as
>> container objects (I posted a series the other week that starts
>> to move in that direction by dropping the weird subclassing of
>> the
Il 13/04/2012 11:09, Peter Maydell ha scritto:
> On 13 April 2012 09:33, Paolo Bonzini 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 re
On 13 April 2012 09:33, Paolo Bonzini 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.
>
> Y
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 reg
On 13 April 2012 08:59, Paolo Bonzini wrote:
> Il 13/04/2012 09:30, Peter Maydell ha scritto:
>> ...but it's not uncommon for the number of memory regions or
>> IRQs to depend on some qdev property, so you can't put these
>> calls in instance_init, that would be too early.
>
> Do you have examples
Il 13/04/2012 09:30, Peter Maydell ha scritto:
> ...but it's not uncommon for the number of memory regions or
> IRQs to depend on some qdev property, so you can't put these
> calls in instance_init, that would be too early.
Do you have examples? The only example I can find in the tree from a
quic
On 13 April 2012 08:17, Paolo Bonzini wrote:
> Il 12/04/2012 23:08, Andreas Färber ha scritto:
> If you look at the initialization of a typical qdev object, it goes like
> this:
>
> dev = qdev_create(NULL, "mv88w8618_eth");
> qdev_set_nic_properties(dev, &nd_table[0]);
> qdev_init_nofail(
Il 12/04/2012 23:08, Andreas Färber ha scritto:
> Reality with SysBus is multi-stage constructors:
> A = qdev_create()
> A.a = x
> qdev_init_nofail(A) -> A_initfn() -> B = qdev_create()
> B.b = y
> qdev_init_nofail(B) -> B_in
Am 13.04.2012 00:09, schrieb Anthony Liguori:
> On 04/12/2012 05:02 PM, Andreas Färber wrote:
>> Am 12.04.2012 23:24, schrieb Anthony Liguori:
>>> I guess I don't understand what the problem we're trying to solve is.
>>>
>>> Why can't we introduce an Object::realize() and just have it not
>>> autom
Am 12.04.2012 23:24, schrieb Anthony Liguori:
> I think you're trying to run before we walk.
The opposite is the case: I am trying to walk by improving code that was
not even qdev'ified before I touched it (see the sh4 commit in my
previous message). But now you are telling me I can't get a functi
On 12 April 2012 22:57, Anthony Liguori wrote:
> On 04/12/2012 04:50 PM, Peter Maydell wrote:
>> My main desire from shifting to QOM is named connections between
>> devices and killing off the strict hierarchy of qbus buses;
>
> We're pretty much there, no?
>
> I think the only thing really left i
On 04/12/2012 05:02 PM, Andreas Färber wrote:
Am 12.04.2012 23:24, schrieb Anthony Liguori:
I guess I don't understand what the problem we're trying to solve is.
Why can't we introduce an Object::realize() and just have it not
automatically call DeviceState::init()? That way we have a way to
c
Am 12.04.2012 23:24, schrieb Anthony Liguori:
> I guess I don't understand what the problem we're trying to solve is.
>
> Why can't we introduce an Object::realize() and just have it not
> automatically call DeviceState::init()? That way we have a way to
> clearly indicate whether a device needs
On 04/12/2012 04:50 PM, Peter Maydell wrote:
On 12 April 2012 22:24, Anthony Liguori wrote:
The end goal shouldn't be s/qdev/object/g. That doesn't make things better
by just using a new shiny infrastructure. Splitting device initialization
into two stages is the fundamental reason for introd
On 12 April 2012 22:24, Anthony Liguori wrote:
> The end goal shouldn't be s/qdev/object/g. That doesn't make things better
> by just using a new shiny infrastructure. Splitting device initialization
> into two stages is the fundamental reason for introducing QOM in the first
> place.
It might
On 04/12/2012 04:08 PM, Andreas Färber wrote:
Am 12.04.2012 21:59, schrieb Anthony Liguori:
On 04/12/2012 11:52 AM, Andreas Färber wrote:
Am 12.04.2012 17:41, schrieb Anthony Liguori:
On 04/12/2012 09:04 AM, Andreas Färber wrote:
Am 12.04.2012 16:59, schrieb Paolo Bonzini:
Il 12/04/2012 16:4
Am 12.04.2012 21:59, schrieb Anthony Liguori:
> On 04/12/2012 11:52 AM, Andreas Färber wrote:
>> Am 12.04.2012 17:41, schrieb Anthony Liguori:
>>> On 04/12/2012 09:04 AM, Andreas Färber wrote:
Am 12.04.2012 16:59, schrieb Paolo Bonzini:
> Il 12/04/2012 16:47, Anthony Liguori ha scritto:
>>
On 04/12/2012 11:52 AM, Andreas Färber wrote:
Am 12.04.2012 17:41, schrieb Anthony Liguori:
On 04/12/2012 09:04 AM, Andreas Färber wrote:
Am 12.04.2012 16:59, schrieb Paolo Bonzini:
Il 12/04/2012 16:47, Anthony Liguori ha scritto:
Wrap setting of Object::realized property, error reporting a
On 04/12/2012 12:02 PM, Paolo Bonzini wrote:
Il 12/04/2012 18:52, Andreas Färber ha scritto:
Selecting the type of an object should be done by having a link<>
property and letting the user create an object and setup the link.
No, that's not what a link does. A link<> property lets the user
as
Il 12/04/2012 18:52, Andreas Färber ha scritto:
>> Selecting the type of an object should be done by having a link<>
>> property and letting the user create an object and setup the link.
>
> No, that's not what a link does. A link<> property lets the user
> associate one instance, not a type that
Am 12.04.2012 17:41, schrieb Anthony Liguori:
> On 04/12/2012 09:04 AM, Andreas Färber wrote:
>> Am 12.04.2012 16:59, schrieb Paolo Bonzini:
>>> Il 12/04/2012 16:47, Anthony Liguori ha scritto:
> Wrap setting of Object::realized property, error reporting and exit(1)
> into a helper fun
Am 12.04.2012 16:47, schrieb Anthony Liguori:
> On 04/12/2012 08:44 AM, Andreas Färber wrote:
>> Wrap setting of Object::realized property, error reporting and exit(1)
>> into a helper function. It is the equivalent of qdev_init_nofail().
>
> I don't like this.
>
> If for no reason other than, a
On 04/12/2012 11:09 AM, Peter Maydell wrote:
On 12 April 2012 17:02, Anthony Liguori wrote:
On 04/12/2012 10:52 AM, Peter Maydell wrote:
Why would you design an infrastructure that lets you coherently bundle
together a collection of devices and have configurable properties on
that bundle as we
Il 12/04/2012 18:09, Peter Maydell ha scritto:
> On 12 April 2012 17:02, Anthony Liguori wrote:
>> On 04/12/2012 10:52 AM, Peter Maydell wrote:
>>> Why would you design an infrastructure that lets you coherently bundle
>>> together a collection of devices and have configurable properties on
>>> th
On 12 April 2012 17:02, Anthony Liguori wrote:
> On 04/12/2012 10:52 AM, Peter Maydell wrote:
>> Why would you design an infrastructure that lets you coherently bundle
>> together a collection of devices and have configurable properties on
>> that bundle as well as on the devices, and then *not* u
On 04/12/2012 10:52 AM, Peter Maydell wrote:
On 12 April 2012 16:43, Anthony Liguori wrote:
I don't think machines should be objects.
Chipsets should be QOM objects. What the machines currently do does not map
well to modeling as an object.
Why would you design an infrastructure that lets y
Am 12.04.2012 17:43, schrieb Anthony Liguori:
> On 04/12/2012 10:15 AM, Paolo Bonzini wrote:
>> Il 12/04/2012 15:58, Andreas Färber ha scritto:
>>> The big clash that Paolo and I had turned out to stem from tackling two
>>> virtually inconsolable goals, both under the banner of "realize":
>>
>> I t
On 12 April 2012 16:43, Anthony Liguori wrote:
> I don't think machines should be objects.
>
> Chipsets should be QOM objects. What the machines currently do does not map
> well to modeling as an object.
Why would you design an infrastructure that lets you coherently bundle
together a collection
On 04/12/2012 10:15 AM, Paolo Bonzini wrote:
Il 12/04/2012 15:58, Andreas Färber ha scritto:
The big clash that Paolo and I had turned out to stem from tackling two
virtually inconsolable goals, both under the banner of "realize":
I think the code was similar enough that the goals are not
unre
On 04/12/2012 09:04 AM, Andreas Färber wrote:
Am 12.04.2012 16:59, schrieb Paolo Bonzini:
Il 12/04/2012 16:47, Anthony Liguori ha scritto:
Wrap setting of Object::realized property, error reporting and exit(1)
into a helper function. It is the equivalent of qdev_init_nofail().
I don't like
Il 12/04/2012 16:47, Anthony Liguori ha scritto:
>
>> Wrap setting of Object::realized property, error reporting and exit(1)
>> into a helper function. It is the equivalent of qdev_init_nofail().
>
> I don't like this.
>
> If for no reason other than, a much more specific justification is
> need
Il 12/04/2012 15:58, Andreas Färber ha scritto:
> The big clash that Paolo and I had turned out to stem from tackling two
> virtually inconsolable goals, both under the banner of "realize":
I think the code was similar enough that the goals are not
unreconcilable (though QOM goals can certainly be
Am 12.04.2012 16:59, schrieb Paolo Bonzini:
> Il 12/04/2012 16:47, Anthony Liguori ha scritto:
>>
>>> Wrap setting of Object::realized property, error reporting and exit(1)
>>> into a helper function. It is the equivalent of qdev_init_nofail().
>>
>> I don't like this.
>>
>> If for no reason other
On 04/12/2012 08:44 AM, Andreas Färber wrote:
Wrap setting of Object::realized property, error reporting and exit(1)
into a helper function. It is the equivalent of qdev_init_nofail().
I don't like this.
If for no reason other than, a much more specific justification is needed for
this. I ab
Wrap setting of Object::realized property, error reporting and exit(1)
into a helper function. It is the equivalent of qdev_init_nofail().
Signed-off-by: Andreas Färber
Cc: Anthony Liguori
Cc: Paolo Bonzini
Cc: Peter Maydell
---
Hi Paolo, please consider appending this patch to your push-push
51 matches
Mail list logo
