qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] KVM call minutes for Feb 8
Date: Tue, 15 Feb 2011 17:07:07 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

On 02/15/2011 11:11 AM, Blue Swirl wrote:
On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori<address@hidden>  wrote:
Any device we expose to the user through -device needs to maintain a
compatible interface forever.  For our own sanity, I think we should try to
expose as little as possible.
Restricting the users from adding arbitrary devices is a different
issue. Dropping qdev support to prevent user from adding the device
seems draconian, what's wrong with no_user flag?

I think you're missing my point.

It should be possible to make a device "qdev" without exposing it via a factory interface. Today it's all or nothing and that's the part I dislike.

no_user is a hack.  We can do better.

A good example of a device that we should model through qdev but not expose
via -device is actually SerialState.
You wouldn't want users to add any serial ports? What should be do
with serial ports then, always enable a full set of ports? How would
the user use them?

No, users should be able to create ISASerialDevice, MMIOSerialDevice, but not UART16650A. Here's what I'm talking about:

class ISASerialDevice : public ISADevice
{
    UART16650A uart;
};

class MMIOSerialDevice : public PlatformDevice
{
    UART16650A uart;
};

There should be factory interfaces for ISASeriaDevice and MMIOSerialDevice but not UART16650A.

Today, we have ISASerialState which embeds SerialState.  We can also create
a MMIO version of SerialState although there's no direct structure that
wraps that.

Ideally, SerialState would be a proper qdev device that is embedded in both
ISASerialState and MMIOSerialState (or pick a better name).  info qtree
should show a has-a relationship for these devices.
I think the devices shown in qtree should always have some
relationship to real devices. If ICH10 contains all possible onboard
devices, including for example HPET, e1000 and SATA, that could use a
has-a relationship to show the composition

Yeah, I'm not disagreeing at all.

Ignoring the fact that modern uarts are implemented in a super i/o chip, it's same chip whether it's soldered directly on a board with direct connections to a CPU bus or whether it's exposed on the ISA bus.

Regards,

Anthony Liguori

  but otherwise I fear this
would only increase complexity with no gain.





reply via email to

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