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

[Anthony Liguori]

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.

> > > 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.

> 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.

Regards,

Anthony Liguori

> Jan
>
>