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: Mon, 14 Feb 2011 15:47:06 -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/14/2011 03:25 PM, Blue Swirl wrote:
I'd still like to have the inline wrapper over the factory interface,
probably with similar signature to isa_serial_new. Then there would be
two functions, one going through qdev and the other bypassing it. I
don't see how that would be useful.

The callers of the direct interface would force linkage between them
and so it would be impossible to build QEMU with that device. We don't
need that flexibility for every device though, but I don't see any
advantages for using the direct interface either.

Why shouldn't we want all devices to be exposed to the user? For
example, there are still devices which don't show up in 'info qtree',
which is a shame.

Showing up in info qtree is goodness, but I'm talking about allowing a user to directly instantiate a device.

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.

A good example of a device that we should model through qdev but not expose via -device is actually SerialState.

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.

Regards,

Anthony Liguori





reply via email to

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