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 r
On Tue, Feb 8, 2011 at 3:55 PM, Chris Wright 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 kvm" in
the body
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 o
Chris Wright 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 ideas welcome.
On 8 February 2011 17:13, Markus Armbruster 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 remaining
On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
> Chris Wright 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
On 08.02.2011, at 18:13, Markus Armbruster wrote:
> Chris Wright 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 i
On 02/08/2011 11:13 AM, Markus Armbruster wrote:
Chris Wright 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 c
On 02/08/2011 01:02 PM, Peter Maydell wrote:
On 8 February 2011 17:13, Markus Armbruster 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 mo
Anthony Liguori writes:
> On 02/08/2011 11:13 AM, Markus Armbruster wrote:
>> Chris Wright 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:
>>
>> * Furth
Peter Maydell writes:
> On 8 February 2011 17:13, Markus Armbruster 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
>> alway
On 9 February 2011 08:11, Markus Armbruster wrote:
> Peter Maydell writes:
>> Markus Armbruster 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 question is: where is the documentation on how to
Aurelien Jarno writes:
> On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
>> Chris Wright 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:
>>
>>
Peter Maydell writes:
> On 9 February 2011 08:11, Markus Armbruster wrote:
>> Peter Maydell writes:
>>> Markus Armbruster 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 question is: wher
On 02/09/2011 02:01 AM, Markus Armbruster wrote:
Anthony Liguori writes:
On 02/08/2011 11:13 AM, Markus Armbruster wrote:
Chris Wright writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concer
On 02/08/2011 01:30 PM, Aurelien Jarno wrote:
On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
Chris Wright writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concerned, I can see two kinds o
Anthony Liguori writes:
> On 02/09/2011 02:01 AM, Markus Armbruster wrote:
>> Anthony Liguori writes:
[...]
>>> We need to unify the property model. We have QemuOpts, qdev
>>> properties, and QObject which basically reinvents variant typing three
>>> different ways.
>>>
>> Make it four: Q
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 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 Wright writes:
>>>
>>> [...]
>>>
- qdev/vmstate both examples of partially completed work tha
On Wed, Feb 9, 2011 at 4:44 PM, Anthony Liguori 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 convert
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 se
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 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 Liguori 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,
On 10 February 2011 07:47, Anthony Liguori 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 anything other than t
On 02/10/2011 09:16 AM, Peter Maydell wrote:
On 10 February 2011 07:47, Anthony Liguori 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 mach
On 10 February 2011 08:36, Anthony Liguori wrote:
> On 02/10/2011 09:16 AM, Peter Maydell wrote:
>> On 10 February 2011 07:47, Anthony Liguori wrote:
>>> 2) get rid of the entire concept of machines. Creating a i440fx is
>>> essentially equivalent to creating a bare machine.
>>
>> Does that make
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 Liguori
> >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 leas
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'
On 02/10/2011 10:04 AM, Peter Maydell wrote:
On 10 February 2011 08:36, Anthony Liguori wrote:
On 02/10/2011 09:16 AM, Peter Maydell wrote:
On 10 February 2011 07:47, Anthony Liguoriwrote:
2) get rid of the entire concept of machines. Creating a i440fx is
essentially eq
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 Liguori
wrote:
> >>On 02/09/2011 06:48 PM, Blue Swirl wrote:
> ISASerialState dev;
>
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 all
On 10 February 2011 10:13, Anthony Liguori wrote:
> On 02/10/2011 10:04 AM, Peter Maydell wrote:
>>
>> On 10 February 2011 08:36, Anthony Liguori wrote:
>>> So you would model arm926ej-s as the chipset and then build up the
>>> machines
>>> by modifying parameters of the chipset (like the board i
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.
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 Liguori
> >> wrote:
> >> >
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 w
On 02/10/2011 11:38 AM, Peter Maydell wrote:
On 10 February 2011 10:13, Anthony Liguori wrote:
On 02/10/2011 10:04 AM, Peter Maydell wrote:
On 10 February 2011 08:36, Anthony Liguoriwrote:
So you would model arm926ej-s as the chipset and then build up the
machines
by mod
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 interna
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 the
On 10 February 2011 12:23, Anthony Liguori 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 bus is kind of compli
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 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
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 singl
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 pin
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 if(
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 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 with qdev again (not that I am a big qdev fan)?
We've really been arguing abo
On Thu, 10 Feb 2011 08:16:15 +
Peter Maydell wrote:
> On 10 February 2011 07:47, Anthony Liguori 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
On 10 February 2011 19:17, Scott Wood wrote:
> On Thu, 10 Feb 2011 08:16:15 +
> Peter Maydell wrote:
>> On 10 February 2011 07:47, Anthony Liguori wrote:
>> > So very concretely, I'm suggesting we do the following to target-i386:
>>
>> > 2) get rid of the entire concept of machines. Creatin
On Thu, 10 Feb 2011 19:22:38 +
Peter Maydell wrote:
> On 10 February 2011 19:17, Scott Wood wrote:
> > On Thu, 10 Feb 2011 08:16:15 +
> > Peter Maydell wrote:
> >> On 10 February 2011 07:47, Anthony Liguori wrote:
> >> > So very concretely, I'm suggesting we do the following to target-
On Thu, Feb 10, 2011 at 9:47 AM, Anthony Liguori wrote:
> On 02/09/2011 09:15 PM, Blue Swirl wrote:
>>
>> On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori
>> wrote:
>>
>>>
>>> On 02/09/2011 06:48 PM, Blue Swirl wrote:
>>>
>
> ISASerialState dev;
>
> isa_serial_init(&dev, 0, 0x274,
On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori 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 with qdev agai
On Fri, Feb 11, 2011 at 08:14:16PM +0200, Blue Swirl wrote:
> On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori
> 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/11/2011 12:14 PM, Blue Swirl wrote:
On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori 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 o
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 e
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 e
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 in
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 o
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.
> >
> >S
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori wrote:
> On 02/11/2011 12:14 PM, Blue Swirl wrote:
>>
>> On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori
>> wrote:
>>
>>>
>>> On 02/10/2011 03:20 PM, Gleb Natapov wrote:
>>>
Jugging by how well all previous conversion went we will end up
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 full
On 02/13/2011 01:37 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori 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 property framework that inc
On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguori wrote:
> On 02/13/2011 01:37 PM, Blue Swirl wrote:
>>
>> On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori
>> wrote:
>>
>>>
>>> qdev doesn't expose any state today. qdev properties are
>>> construction-only
>>> properties that happen to be stored i
On 13 February 2011 16:56, Anthony Liguori 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 i440fx,cpus=cpus
>
> I
On 02/13/2011 03:00 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguori wrote:
On 02/13/2011 01:37 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori
wrote:
qdev doesn't expose any state today. qdev properties are
construction-only
On 02/13/2011 03:24 PM, Peter Maydell wrote:
On 13 February 2011 16:56, Anthony Liguori 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=c
On 13 February 2011 22:43, Anthony Liguori 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 parts of the addres
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 is
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
> c
On Mon, Feb 14, 2011 at 12:42 AM, Anthony Liguori wrote:
> On 02/13/2011 03:00 PM, Blue Swirl wrote:
>>
>> On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguori
>> wrote:
>>
>>>
>>> On 02/13/2011 01:37 PM, Blue Swirl wrote:
>>>
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori
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. serial_init(), that may be
true since isa_serial_init has to check for qdev failures, but the t
On Mon, Feb 14, 2011 at 10:53 PM, Anthony Liguori 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. serial_
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 calle
On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori 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 through qdev and th
On 02/15/2011 11:11 AM, Blue Swirl wrote:
On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori 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 possible.
Restrictin
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 Liguori
> >wrote:
> >>Any device we expose to the user through -device needs to maintain a
> >>compatible interface forever. For our own sanit
79 matches
Mail list logo
