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

[Jan Kiszka]

On 2011-03-07 15:57, Anthony Liguori wrote:
> On 03/07/2011 01:58 AM, Jan Kiszka wrote:
>> 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.
>>    
> 
> And as soon as we do time drift catch-up, it's going to be an important
> interface to work with.

/me confused. How does this relate to the original topic?

> 
>>>> 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.
>>    
> 
> We can convert it to a DeviceState, and then have it hang off of Sysbus
> (but created under PIIX3).  It's less pretty from a tree perspective but
> at least the modelling is correct.
> 
> We should model based on logic relationships, not how we want things to
> look in info qtree.

That looks fairly odd to me compared to other ISA/LPC-attached devices.
Without better alternatives, consistency of the existing model is more
important IMO.

> 
>> 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.
>>    
> 
> My biggest concern moving forward is that the more legacy baggage we
> accumulate with the current qdev implementation, the tougher its going
> to be to improve it down the road.

Sticking with open-coded devices until some magic, perfect, easily
introduceable qdev 2.0 arrives is worse than continuing the cleanup work
and make all devices more regular and explorable. That's even more true
as this conversion comes with no relevant legacy baggage IMHO. Moreover,
every conversion that is done now (as the trivial ones are mostly
through) gives valuable input for necessary improvements of qdev.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux