qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 4/4] i8254: convert to qdev


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 4/4] i8254: convert to qdev
Date: Mon, 07 Mar 2011 08:58:04 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-03-07 01:32, Anthony Liguori wrote:
> On 03/06/2011 03:18 PM, Jan Kiszka wrote:
>>> It's far from academic as this is user-visible and visible via the
>>> command line.
>>>      
>> I thought it was stated before that there is no guarantee on the
>> internal structure of our device tree as the user may explore it (as
>> long as it's stable for the guest).
> 
> We have a lot of "unstable" interfaces that folks yell about every time
> it changes (like the -help output).  Providing a bad external interface
> and justifying by saying its unstable is just asking for pain later.

This is really a "harmless", mostly read-only interface we are
discussing here.

> 
>>   Regarding command line: What are
>> your worries here? The user can't mess with built-in devices.
>>    
> 
> -global still applies to no_user devices.

Already tried "-global isa-pit.iobase=0x4711"? -global changes property
defaults, not directly their values.

> 
>> I still think we have more important things to improve than these
>> cosmetic issues.
>>    
> 
> What does converting this device to qdev actually add other than an
> interface that we're not going to be able to support long term?

This device is probably no big deal. But generally those conversions
help to clean up or at least uncover twisted dependencies between
devices. They are surely a step in the right direction as everything
that follows qdev will have to improve it evolutionary (we can't effort
a third device model in qemu), so will be able to build on top.

The major issues I see when looking at more complex devices,
specifically in the x86 world:
 - IRQ/GPIO binding should become a generic qdev service instead of a
   sysbus bonus (and its interface should be improved).
 - Buses may benefit from generic IRQ management as well.
 - We need a generic connector between devices, maybe multi-bus binding
   (e.g. to bind the IOAPIC both to the sysbus and the inter-processor
   bus), maybe PROP_TYPE_BUS that could be set via qtree path or
   alternatively a plain pointer. That should obsolete PROP_TYPE_PTR.

And there are likely thousand things in the qdev model that could be
made simpler, more handy to use.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]