From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <aliguori@us.ibm.com>
Subject: Re: [PATCH v8 18/18] kvm: Activate in-kernel irqchip
	support
Date: Tue, 24 Jan 2012 09:34:58 -0600
Message-ID: <4F1ECFA2.4000304@us.ibm.com>
References: <cover.1326972302.git.jan.kiszka@siemens.com>	<6a48ffaaa732b2142c1b5030178f2d4a0fa499fe.1326972302.git.jan.kiszka@siemens.com>	<20120119180851.GA19099@amt.cnet>
	<4F1866E0.7010900@web.de>	<4F1EBAAF.8040808@redhat.com>
	<4F1EBBD7.2050007@siemens.com> <4F1EBC8D.5000403@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>, Blue Swirl <blauwirbel@gmail.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <4F1EBC8D.5000403@redhat.com>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

On 01/24/2012 08:13 AM, Avi Kivity wrote:
> On 01/24/2012 04:10 PM, Jan Kiszka wrote:
>> On 2012-01-24 15:05, Avi Kivity wrote:
>>> On 01/19/2012 08:54 PM, Jan Kiszka wrote:
>>>> Nope, see kvm_irqchip_create, patch 13. You can also check by browsing
>>>> the qtree (different device model names).
>>>
>>> That was my biggest objection to the previous iterations.  Later
>>> versions changed to use an attribute (selecting the backend).  What
>>> happened now?
>>
>> The other approach was rejected.
>
> Sigh.  We'll regret this.

No we won't.  The other approach was creating a mini-qdev as a mechanism to hide 
the fact that we have two different implementations of the same device.

We need to expose this information to the user in some fashion.  The type is the 
natural way to do it.

Regards,

Anthony Liguori

>
>> Moreover, see http://thread.gmane.org/gmane.comp.emulators.qemu/129659,
>> QOM will allow addressing with identical paths.
>
> At least that.