[Top][All Lists]

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

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

From: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCH 4/4] i8254: convert to qdev
Date: Mon, 07 Mar 2011 08:57:49 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

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.


Anthony Liguori


reply via email to

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