On 02/07/2012 12:17 PM, Andreas Färber wrote:
Am 07.02.2012 19:01, schrieb Anthony Liguori:
On 02/07/2012 07:45 AM, Andreas Färber wrote:
http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html
How is the realize step (DeviceState::init) supposed to translate to
Object-derived class
Am 07.02.2012 19:01, schrieb Anthony Liguori:
> On 02/07/2012 07:45 AM, Andreas Färber wrote:
>> http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html
>>
>> How is the realize step (DeviceState::init) supposed to translate to
>> Object-derived classes (e.g., CPU) and where to draw the
On 02/07/2012 07:45 AM, Andreas Färber wrote:
Am 06.02.2012 20:25, schrieb Juan Quintela:
Please send in any agenda items you are interested in covering.
I had some follow-up questions to the last call that remained
unanswered. We don't really need a call for that though, email is fine.
http:
On 02/07/2012 05:33 PM, Anthony Liguori wrote:
Hrm, I don't like that very much.
Yes, me neither actually.
If the object representing the state of the OMAP board (struct
omap_mpu_state_s) is QOMified, the clocks can easily get under it in the
composition tree. Right now, that part is not ev
On 02/07/2012 10:41 AM, Andreas Färber wrote:
Am 07.02.2012 16:21, schrieb Paolo Bonzini:
BTW, I would like to change /i440fx to /devices/i440fx, so that we will
have clean namespaces:
/block
...
/chardev
...
/clocks
...
/devices
/peripheral
... # na
Am 07.02.2012 16:21, schrieb Paolo Bonzini:
> BTW, I would like to change /i440fx to /devices/i440fx, so that we will
> have clean namespaces:
>
> /block
> ...
> /chardev
> ...
> /clocks
> ...
> /devices
> /peripheral
> ... # named devices created with -devi
On 7 February 2012 16:33, Anthony Liguori wrote:
> OMAP clocks are devices. Don't they belong in the devices hierarchy under
> the omap-clocks branch?
I think they should be interfaces, not devices. The device would be the PRCM
(power, reset and clock manager) which provides a pile of registers
On 02/07/2012 10:27 AM, Paolo Bonzini wrote:
On 02/07/2012 05:24 PM, Anthony Liguori wrote:
I'm wary of all plans that require to go through all the code once. What about
simply /devices/default/child[...] or something like that?
The paths would be unstable, but maybe that's okay. I'd suggest
On 02/07/2012 05:24 PM, Anthony Liguori wrote:
I'm wary of all plans that require to go through all the code once. What about
simply /devices/default/child[...] or something like that?
The paths would be unstable, but maybe that's okay. I'd suggest
doing child[rand()] to avoid the appearance t
On 02/07/2012 09:21 AM, Paolo Bonzini wrote:
On 02/07/2012 03:56 PM, Anthony Liguori wrote:
Another related question is, should the 4th QOM series present a full
composition tree based on the legacy qdev bus concept?
Composition, no. The legacy qbus concept doesn't model composition
because it
On 02/07/2012 03:56 PM, Anthony Liguori wrote:
Another related question is, should the 4th QOM series present a full
composition tree based on the legacy qdev bus concept?
Composition, no. The legacy qbus concept doesn't model composition
because it puts children created by composition (like th
On 02/07/2012 07:52 AM, Paolo Bonzini wrote:
On 02/07/2012 02:45 PM, Andreas Färber wrote:
Another topic that can be answered by email is what the time planning
for the 4th QOM series looks like.
qom-upstream.16 is pretty close to ready to be sent out for v1. It's fairly
tricky getting these
Juan Quintela wrote:
> Hi
>
> Please send in any agenda items you are interested in covering.
As there were only one topic for the call, and Andreas suggested to use
email, we cancel this week call.
Have a nice day, Juan.
On 02/07/2012 02:45 PM, Andreas Färber wrote:
Another topic that can be answered by email is what the time planning
for the 4th QOM series looks like. Are there things that developers of
new devices should keep in mind / start doing differently wrt SysBus?
Another related question is, should th
Am 06.02.2012 20:25, schrieb Juan Quintela:
> Please send in any agenda items you are interested in covering.
I had some follow-up questions to the last call that remained
unanswered. We don't really need a call for that though, email is fine.
http://lists.gnu.org/archive/html/qemu-devel/2012-01/
Hi
Please send in any agenda items you are interested in covering.
Cheers,
Juan.
16 matches
Mail list logo
