From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Date: Wed, 16 Feb 2011 11:52:03 +0200 Message-ID: <20110216095203.GC14984@redhat.com> References: <4D583793.10409@codemonkey.ws> <4D585E3C.9010404@codemonkey.ws> <4D599639.2030508@codemonkey.ws> <4D59A2DA.6060705@codemonkey.ws> <4D5B071B.6060900@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Blue Swirl , Chris Wright , kvm@vger.kernel.org, qemu-devel@nongnu.org, Markus Armbruster , Avi Kivity To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37343 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754055Ab1BPJwH (ORCPT ); Wed, 16 Feb 2011 04:52:07 -0500 Content-Disposition: inline In-Reply-To: <4D5B071B.6060900@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54128 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ppe3M-0002H9-TA for qemu-devel@nongnu.org; Wed, 16 Feb 2011 04:52:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ppe3L-0006DJ-BK for qemu-devel@nongnu.org; Wed, 16 Feb 2011 04:52:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46766) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ppe3K-0006D7-V8 for qemu-devel@nongnu.org; Wed, 16 Feb 2011 04:52:07 -0500 Date: Wed, 16 Feb 2011 11:52:03 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Message-ID: <20110216095203.GC14984@redhat.com> References: <4D583793.10409@codemonkey.ws> <4D585E3C.9010404@codemonkey.ws> <4D599639.2030508@codemonkey.ws> <4D59A2DA.6060705@codemonkey.ws> <4D5B071B.6060900@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D5B071B.6060900@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , kvm@vger.kernel.org, qemu-devel@nongnu.org, Markus Armbruster , Blue Swirl , Avi Kivity 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 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.