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

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

 



On Tue, Feb 15, 2011 at 05:07:07PM -0600, Anthony Liguori wrote:
> On 02/15/2011 11:11 AM, Blue Swirl wrote:
> >On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori<anthony@xxxxxxxxxxxxx>  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.
> 
I think you are mixing too different thing here. The purpose of qdev (or
other device tree implementation) should be 1. to provide factory
interface. 2 to keep track on how devices are interconnected (or in
other words to keep track of device tree). But you are constantly
talking about how qdev should be object oriented way to build devices
themselves and I think this shouldn't be part of qdev at all.

> 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.
This is OK and I do not disagree with this, but this is not what qdev
should be about. Qdev should be about allowing user to specify how and
which classes (read devices) should be instantiated at how they should
be interconnected. Taking yous example above qdev should allow to say: I
want to instantiate ISASerialDevice on bus object isabus0 (which was
instantiated before). It should claim resources A, B and C from that
bus. I also what instantiate MMIOSerialDevice on bus object systembus
claiming resource Z.

--
			Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux