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.
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
Juan Quintela quint...@redhat.com 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.
--
To unsubscribe from this list: send the line
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
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
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
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
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 7 February 2012 16:33, Anthony Liguori anth...@codemonkey.ws 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
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 -device
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
... #
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
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.
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 line
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
Hi
Please send in any agenda items you are interested in covering.
Cheers,
Juan.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
16 matches
Mail list logo
