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

[Blue Swirl]

On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori <address@hidden> wrote:
> 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.

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?

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

> 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 but otherwise I fear this
would only increase complexity with no gain.