On Tue, Feb 15, 2011 at 05:07:07PM -0600, Anthony Liguori wrote:
On 02/15/2011 11:11 AM, Blue Swirl wrote:
On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
Any device we expose to the user through -device needs to maintain a
compatible interface forever. For
On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/14/2011 03:25 PM, Blue Swirl wrote:
I'd still like to have the inline wrapper over the factory interface,
probably with similar signature to isa_serial_new. Then there would be
two functions, one going
On 02/15/2011 11:11 AM, Blue Swirl wrote:
On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguorianth...@codemonkey.ws wrote:
Any device we expose to the user through -device needs to maintain a
compatible interface forever. For our own sanity, I think we should try to
expose as little as
On 02/13/2011 08:57 PM, Anthony Liguori wrote:
It shouldn't be able to dead lock if the locking is designed right.
As an aside, one advantage of the qemuthread wrappers is that we can add
lockdep mechanisms. (It's true that these could be added to glib as
well, but getting stuff into glib
On Sun, Feb 13, 2011 at 01:38:12PM -0600, Anthony Liguori wrote:
On 02/13/2011 12:08 PM, Gleb Natapov wrote:
On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote:
qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device
ioapic,id=ioapic,chipset=sb -device
On Mon, Feb 14, 2011 at 12:42 AM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/13/2011 03:00 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
On 02/13/2011 01:37 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 5:31 PM, Anthony
On 02/14/2011 11:31 AM, Blue Swirl wrote:
I don't understand. The caller just does
if (isa_serial_init()) {
error();
}
or
if (serial_init()) {
error();
}
If you mean inside isa_serial_init() vs. serial_init(), that may be
true since isa_serial_init has to check for qdev failures, but the
On Mon, Feb 14, 2011 at 10:53 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/14/2011 11:31 AM, Blue Swirl wrote:
I don't understand. The caller just does
if (isa_serial_init()) {
error();
}
or
if (serial_init()) {
error();
}
If you mean inside isa_serial_init() vs.
On 02/14/2011 03:25 PM, Blue Swirl wrote:
I'd still like to have the inline wrapper over the factory interface,
probably with similar signature to isa_serial_new. Then there would be
two functions, one going through qdev and the other bypassing it. I
don't see how that would be useful.
The
On Fri, Feb 11, 2011 at 08:14:16PM +0200, Blue Swirl wrote:
On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
On 02/10/2011 03:20 PM, Gleb Natapov wrote:
Jugging by how well all previous conversion went we will end up with one
more way of creating devices.
On 02/11/2011 12:14 PM, Blue Swirl wrote:
On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguorianth...@codemonkey.ws wrote:
On 02/10/2011 03:20 PM, Gleb Natapov wrote:
Jugging by how well all previous conversion went we will end up with one
more way of creating devices. One legacy,
On 02/10/2011 04:29 AM, Avi Kivity wrote:
On 02/10/2011 09:47 AM, Anthony Liguori wrote:
So very concretely, I'm suggesting we do the following to target-i386:
1) make the i440fx device have an embedded ide controller, piix3, and
usb controller that get initialized automatically. The piix3
On 02/10/2011 04:29 AM, Avi Kivity wrote:
On 02/10/2011 09:47 AM, Anthony Liguori wrote:
So very concretely, I'm suggesting we do the following to target-i386:
1) make the i440fx device have an embedded ide controller, piix3, and
usb controller that get initialized automatically. The piix3
On 02/13/2011 05:38 PM, Anthony Liguori wrote:
2) get rid of the entire concept of machines. Creating a i440fx is
essentially equivalent to creating a bare machine.
No, it's not. The 440fx does not include an IOAPIC, for example.
There may be other optional components, or differences
On 02/13/2011 09:56 AM, Avi Kivity wrote:
On 02/13/2011 05:38 PM, Anthony Liguori wrote:
2) get rid of the entire concept of machines. Creating a i440fx is
essentially equivalent to creating a bare machine.
No, it's not. The 440fx does not include an IOAPIC, for example.
There may be
On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote:
qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device
ioapic,id=ioapic,chipset=sb -device
cpu,ioapic=ioapic,northbridge=nb
Is not all that unreasonable and presents a fully functioning PC.
Sure. And -M blah is
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/11/2011 12:14 PM, Blue Swirl wrote:
On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
On 02/10/2011 03:20 PM, Gleb Natapov wrote:
Jugging by how well all previous conversion
On 02/13/2011 12:08 PM, Gleb Natapov wrote:
On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote:
qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device
ioapic,id=ioapic,chipset=sb -device
cpu,ioapic=ioapic,northbridge=nb
Is not all that unreasonable and presents a
On 02/13/2011 01:37 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguorianth...@codemonkey.ws wrote:
qdev doesn't expose any state today. qdev properties are construction-only
properties that happen to be stored in each device state.
What we really need is a full
On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/13/2011 01:37 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
qdev doesn't expose any state today. qdev properties are
construction-only
properties that
On 13 February 2011 16:56, Anthony Liguori anth...@codemonkey.ws wrote:
If we can move away from Bus abstraction and to a simpler interface
mechanism, then we can express peer relationships by just having bidirection
references. IOW:
-device cpus,northbridge=nb,id=cpus,count=16 -device
On 02/13/2011 03:00 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguorianth...@codemonkey.ws wrote:
On 02/13/2011 01:37 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
qdev doesn't expose any state
On 02/13/2011 03:24 PM, Peter Maydell wrote:
On 13 February 2011 16:56, Anthony Liguorianth...@codemonkey.ws wrote:
If we can move away from Bus abstraction and to a simpler interface
mechanism, then we can express peer relationships by just having bidirection
references. IOW:
-device
On 13 February 2011 22:43, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/13/2011 03:24 PM, Peter Maydell wrote:
How would this work for systems with multiple CPUs which have different
views of the world? (ie their memory maps differ so that eg some RAM is
shared between them but some
On Thu, Feb 10, 2011 at 9:47 AM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/09/2011 09:15 PM, Blue Swirl wrote:
On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
On 02/09/2011 06:48 PM, Blue Swirl wrote:
ISASerialState dev;
isa_serial_init(dev, 0,
On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/10/2011 03:20 PM, Gleb Natapov wrote:
Jugging by how well all previous conversion went we will end up with one
more way of creating devices. One legacy, another qdev and your new one.
And what is the problem
On 10 February 2011 07:47, Anthony Liguori anth...@codemonkey.ws wrote:
So very concretely, I'm suggesting we do the following to target-i386:
2) get rid of the entire concept of machines. Creating a i440fx is
essentially equivalent to creating a bare machine.
Does that make any sense for
On 02/10/2011 09:16 AM, Peter Maydell wrote:
On 10 February 2011 07:47, Anthony Liguorianth...@codemonkey.ws wrote:
So very concretely, I'm suggesting we do the following to target-i386:
2) get rid of the entire concept of machines. Creating a i440fx is
essentially equivalent
On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote:
On 02/09/2011 09:15 PM, Blue Swirl wrote:
On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
On 02/09/2011 06:48 PM, Blue Swirl wrote:
ISASerialState dev;
isa_serial_init(dev, 0, 0x274, 0x07, NULL,
On 02/10/2011 10:07 AM, Gleb Natapov wrote:
So what if it is easier, it doesn't mean it is correct thing to do.
If we spend the next 10 years trying to do the correct thing for some
arbitrary definition of correct, that's not terribly useful.
It's really simple actually. Let's do the least
On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote:
On 02/10/2011 10:07 AM, Gleb Natapov wrote:
So what if it is easier, it doesn't mean it is correct thing to do.
If we spend the next 10 years trying to do the correct thing for
some arbitrary definition of correct, that's not
On 02/10/2011 10:04 AM, Peter Maydell wrote:
On 10 February 2011 08:36, Anthony Liguorianth...@codemonkey.ws wrote:
On 02/10/2011 09:16 AM, Peter Maydell wrote:
On 10 February 2011 07:47, Anthony Liguorianth...@codemonkey.wswrote:
2) get rid of the entire concept of
On 02/10/2011 11:10 AM, Gleb Natapov wrote:
On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote:
On 02/10/2011 10:07 AM, Gleb Natapov wrote:
So what if it is easier, it doesn't mean it is correct thing to do.
If we spend the next 10 years trying to do the correct
On 02/10/2011 11:07 AM, Gleb Natapov wrote:
On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote:
On 02/09/2011 09:15 PM, Blue Swirl wrote:
On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
On 02/09/2011 06:48 PM, Blue Swirl wrote:
ISASerialState
On 02/10/2011 09:47 AM, Anthony Liguori wrote:
So very concretely, I'm suggesting we do the following to target-i386:
1) make the i440fx device have an embedded ide controller, piix3, and
usb controller that get initialized automatically. The piix3 embeds
the PCI-to-ISA bridge along with
On 10 February 2011 10:13, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/10/2011 10:04 AM, Peter Maydell wrote:
On 10 February 2011 08:36, Anthony Liguorianth...@codemonkey.ws wrote:
So you would model arm926ej-s as the chipset and then build up the
machines
by modifying parameters of
On Thu, Feb 10, 2011 at 11:19:48AM +0100, Anthony Liguori wrote:
On 02/10/2011 11:10 AM, Gleb Natapov wrote:
On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote:
On 02/10/2011 10:07 AM, Gleb Natapov wrote:
So what if it is easier, it doesn't mean it is correct thing to do.
If we
On Thu, Feb 10, 2011 at 12:25:38PM +0200, Avi Kivity wrote:
On 02/10/2011 11:07 AM, Gleb Natapov wrote:
On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote:
On 02/09/2011 09:15 PM, Blue Swirl wrote:
On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguorianth...@codemonkey.ws
On Thu, Feb 10, 2011 at 10:38:53AM +, Peter Maydell wrote:
This is the system diagram for the Versatile Express:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447d/I1007683.html
I don't know what you'd want to claim is a northbridge there.
Basically there's an FPGA with a
On 02/10/2011 11:38 AM, Peter Maydell wrote:
On 10 February 2011 10:13, Anthony Liguorianth...@codemonkey.ws wrote:
On 02/10/2011 10:04 AM, Peter Maydell wrote:
On 10 February 2011 08:36, Anthony Liguorianth...@codemonkey.wswrote:
So you would model arm926ej-s as the
On 02/10/2011 11:49 AM, Gleb Natapov wrote:
On Thu, Feb 10, 2011 at 11:19:48AM +0100, Anthony Liguori wrote:
On 02/10/2011 11:10 AM, Gleb Natapov wrote:
On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote:
On 02/10/2011 10:07 AM, Gleb Natapov wrote:
So
On 02/10/2011 12:13 PM, Gleb Natapov wrote:
Which spec? Even in this discussion we completely mixed different
things. 440FX is not a chipset.
Yes, it is. It's a single silicon package with a defined pinout. If
you don't believe me, re-read the spec.
It's a MCM with the PIIX3 being
On 02/10/2011 02:51 PM, Anthony Liguori wrote:
On 02/10/2011 12:13 PM, Gleb Natapov wrote:
Which spec? Even in this discussion we completely mixed different
things. 440FX is not a chipset.
Yes, it is. It's a single silicon package with a defined pinout. If
you don't believe me, re-read
On 10 February 2011 12:23, Anthony Liguori anth...@codemonkey.ws wrote:
But something interacts with each processor and dispatches the I/O
operations in the address space, no? I can't believe there are 2^32 address
lines coming off of every arm chip that each device connects.
Well, the AXI
On Thu, Feb 10, 2011 at 01:47:06PM +0100, Anthony Liguori wrote:
On 02/10/2011 11:49 AM, Gleb Natapov wrote:
On Thu, Feb 10, 2011 at 11:19:48AM +0100, Anthony Liguori wrote:
On 02/10/2011 11:10 AM, Gleb Natapov wrote:
On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote:
On
On Thu, Feb 10, 2011 at 01:51:14PM +0100, Anthony Liguori wrote:
On 02/10/2011 12:13 PM, Gleb Natapov wrote:
Which spec? Even in this discussion we completely mixed different
things. 440FX is not a chipset.
Yes, it is. It's a single silicon package with a defined pinout.
If you don't
On Thu, Feb 10, 2011 at 03:00:05PM +0200, Avi Kivity wrote:
On 02/10/2011 02:51 PM, Anthony Liguori wrote:
On 02/10/2011 12:13 PM, Gleb Natapov wrote:
Which spec? Even in this discussion we completely mixed different
things. 440FX is not a chipset.
Yes, it is. It's a single silicon
On 02/10/2011 02:00 PM, Avi Kivity wrote:
On 02/10/2011 02:51 PM, Anthony Liguori wrote:
On 02/10/2011 12:13 PM, Gleb Natapov wrote:
Which spec? Even in this discussion we completely mixed different
things. 440FX is not a chipset.
Yes, it is. It's a single silicon package with a defined
On 02/10/2011 02:27 PM, Gleb Natapov wrote:
I don't care how command line will look like, but I do not see how you
will support ide=off without device composition unless you put ad-hoc
ifs all over your i440fx device code.
Yes, in the piix3 device code, the ide property would trigger an
On Thu, Feb 10, 2011 at 03:04:28PM +0100, Anthony Liguori wrote:
On 02/10/2011 02:27 PM, Gleb Natapov wrote:
I don't care how command line will look like, but I do not see how you
will support ide=off without device composition unless you put ad-hoc
ifs all over your i440fx device code.
On Thu, 10 Feb 2011 08:16:15 +
Peter Maydell peter.mayd...@linaro.org wrote:
On 10 February 2011 07:47, Anthony Liguori anth...@codemonkey.ws wrote:
So very concretely, I'm suggesting we do the following to target-i386:
2) get rid of the entire concept of machines. Creating a i440fx
On 10 February 2011 19:17, Scott Wood scottw...@freescale.com wrote:
On Thu, 10 Feb 2011 08:16:15 +
Peter Maydell peter.mayd...@linaro.org wrote:
On 10 February 2011 07:47, Anthony Liguori anth...@codemonkey.ws wrote:
So very concretely, I'm suggesting we do the following to target-i386:
On Thu, 10 Feb 2011 19:22:38 +
Peter Maydell peter.mayd...@linaro.org wrote:
On 10 February 2011 19:17, Scott Wood scottw...@freescale.com wrote:
On Thu, 10 Feb 2011 08:16:15 +
Peter Maydell peter.mayd...@linaro.org wrote:
On 10 February 2011 07:47, Anthony Liguori
Anthony Liguori anth...@codemonkey.ws writes:
On 02/08/2011 11:13 AM, Markus Armbruster wrote:
Chris Wrightchr...@redhat.com writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concerned, I can see two kinds of
Peter Maydell peter.mayd...@linaro.org writes:
On 8 February 2011 17:13, Markus Armbruster arm...@redhat.com wrote:
As far as qdev's concerned, I can see two kinds of to-dos:
* Further develop qdev so that more of the machine init code can becomes
qdev declarations. Specific ideas welcome.
On 9 February 2011 08:11, Markus Armbruster arm...@redhat.com wrote:
Peter Maydell peter.mayd...@linaro.org writes:
Markus Armbruster arm...@redhat.com wrote:
I've said this before: at some point in time (sooner rather than
later, if you ask me), we need to shoot the stragglers.
...and my
Aurelien Jarno aurel...@aurel32.net writes:
On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
Chris Wright chr...@redhat.com writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concerned, I can see two
Peter Maydell peter.mayd...@linaro.org writes:
On 9 February 2011 08:11, Markus Armbruster arm...@redhat.com wrote:
Peter Maydell peter.mayd...@linaro.org writes:
Markus Armbruster arm...@redhat.com wrote:
I've said this before: at some point in time (sooner rather than
later, if you ask
On 02/09/2011 02:01 AM, Markus Armbruster wrote:
Anthony Liguorianth...@codemonkey.ws writes:
On 02/08/2011 11:13 AM, Markus Armbruster wrote:
Chris Wrightchr...@redhat.com writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
On 02/08/2011 01:30 PM, Aurelien Jarno wrote:
On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
Chris Wrightchr...@redhat.com writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concerned, I
Anthony Liguori anth...@codemonkey.ws writes:
On 02/09/2011 02:01 AM, Markus Armbruster wrote:
Anthony Liguorianth...@codemonkey.ws writes:
[...]
We need to unify the property model. We have QemuOpts, qdev
properties, and QObject which basically reinvents variant typing three
different
On 02/09/2011 06:28 AM, Markus Armbruster wrote:
Except that construction of a device requires initialization from an
array of variants (which is then type checked). The way we store the
variants is lossy because we convert back and forth to a string.
Yes, there's overlap, but no, a qdev
On Wed, Feb 9, 2011 at 12:43 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/08/2011 01:30 PM, Aurelien Jarno wrote:
On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
Chris Wrightchr...@redhat.com writes:
[...]
- qdev/vmstate both examples of partially completed
On Wed, Feb 9, 2011 at 4:44 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/09/2011 06:28 AM, Markus Armbruster wrote:
Except that construction of a device requires initialization from an
array of variants (which is then type checked). The way we store the
variants is lossy because we
On 02/09/2011 06:48 PM, Blue Swirl wrote:
We can just do:
ISASerialState dev;
isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL);
Do you mean that there should be a generic way of doing that, like
sysbus_create_varargs() for qdev, or just add inline functions which
hide qdev property
On 02/09/2011 06:48 PM, Blue Swirl wrote:
ISASerialState dev;
isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL);
Do you mean that there should be a generic way of doing that, like
sysbus_create_varargs() for qdev, or just add inline functions which
hide qdev property setup?
I still think
On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/09/2011 06:48 PM, Blue Swirl wrote:
ISASerialState dev;
isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL);
Do you mean that there should be a generic way of doing that, like
sysbus_create_varargs() for qdev,
On 02/09/2011 09:15 PM, Blue Swirl wrote:
On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguorianth...@codemonkey.ws wrote:
On 02/09/2011 06:48 PM, Blue Swirl wrote:
ISASerialState dev;
isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL);
Do you mean that there should be a
Automated builds and testing
- found broken 32-bit
- luiz suggested running against maintainer trees
- daniel gollub offered to take on maintenance
- integration with kvm-autotest?
- lucas, daniel, stefan...
- testing each git commit is probably overkill and too expensive
- current autotest
On Tue, Feb 8, 2011 at 3:55 PM, Chris Wright chr...@redhat.com wrote:
Automated builds and testing
- found broken 32-bit
The broken build was found (and fixed?) before automated qemu.git
builds. It's a good motivator though.
Stefan
--
To unsubscribe from this list: send the line unsubscribe
On 02/08/2011 09:55 AM, Chris Wright wrote:
Automated builds and testing
- found broken 32-bit
- luiz suggested running against maintainer trees
- daniel gollub offered to take on maintenance
- integration with kvm-autotest?
- lucas, daniel, stefan...
- testing each git commit is probably
Chris Wright chr...@redhat.com writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concerned, I can see two kinds of to-dos:
* Further develop qdev so that more of the machine init code can becomes
qdev declarations. Specific
On 8 February 2011 17:13, Markus Armbruster arm...@redhat.com wrote:
As far as qdev's concerned, I can see two kinds of to-dos:
* Further develop qdev so that more of the machine init code can becomes
qdev declarations. Specific ideas welcome. Patches even more, as
always.
* Convert the
On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
Chris Wright chr...@redhat.com writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concerned, I can see two kinds of to-dos:
* Further develop qdev so
On 08.02.2011, at 18:13, Markus Armbruster arm...@redhat.com wrote:
Chris Wright chr...@redhat.com writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concerned, I can see two kinds of to-dos:
* Further develop qdev so
On 02/08/2011 11:13 AM, Markus Armbruster wrote:
Chris Wrightchr...@redhat.com writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concerned, I can see two kinds of to-dos:
* Further develop qdev so that more of the
On 02/08/2011 01:02 PM, Peter Maydell wrote:
On 8 February 2011 17:13, Markus Armbrusterarm...@redhat.com wrote:
As far as qdev's concerned, I can see two kinds of to-dos:
* Further develop qdev so that more of the machine init code can becomes
qdev declarations. Specific ideas
77 matches
Mail list logo
