Re: [Qemu-devel] KVM call minutes for Feb 8

[Markus Armbruster]

Aurelien Jarno <address@hidden> writes:

> On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
>> Chris Wright <address@hidden> 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.  Patches even more, as
>>   always.
>> 
>> * Convert the remaining devices.  They are typically used only with
>>   oddball machines, which makes the conversion hard to test for anyone
>>   who's not already using them.
>> 
>>   I've said this before: at some point in time (sooner rather than
>>   later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>   optimistic that any victims worth keeping will receive timely
>>   attention then.
>> 
>
> For those oddball machines, qdev doesn't really bring anything, that's
> why there is so little interest in converting them, and why I prefer to
> spend my time on the emulation correctness than converting those
> remaining to qdev. Of course I agree it's something to do, and with an
> unlimited amount of free time, I'll do them immediately. 
>
> Let's take for example the SH4 target. It's nice to be able to create 
> the whole machine from a script, except your kernel won't boot if the
> machine:
> - has a different cpu
> - doesn't a SM501 chipset
> - has not the correct memory size
> - doesn't have 2 serial port
>
> That basically only leaves the PCI and USB devices configurable, but
> those are already using qdev.

I understand where you come from.

Converting to qdev isn't free.  But not doing so isn't free either.

QEMU offers two interfaces to device models, legacy and qdev[*].
Maintaining the legacy interface isn't free.  Users of the legacy
interface serve as bad examples.  If we don't pay attention, we can even
get the two mixed up in the same device model.


[*] The two overlap in places.