From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] KVM call minutes for Feb 8
Date: Mon, 14 Feb 2011 15:47:06 -0600
Message-ID: <4D59A2DA.6060705@codemonkey.ws>
References: <AANLkTimtswr5fN9PGVnTSxb9szu12bTC0s4tVwbku-J5@mail.gmail.com>	<4D52F20A.7070009@codemonkey.ws>	<AANLkTi=JzM21XfDR+YO9JY=e8ONGDWVR6YeYdQ7jzzrk@mail.gmail.com>	<4D539800.3070802@codemonkey.ws> <20110210090748.GD673@redhat.com>	<4D53BD22.1040800@redhat.com> <20110210111354.GA21681@redhat.com>	<4D53DF42.4030700@codemonkey.ws> <20110210132730.GB24525@redhat.com>	<4D53F06C.9090500@codemonkey.ws> <20110210142044.GD24525@redhat.com>	<4D540CC5.2@codemonkey.ws>	<AANLkTinQDLT1pLv6NEU+_PYaE-uXMn9vdBKjBo3tU9E0@mail.gmail.com>	<4D57F96B.7010004@codemonkey.ws>	<AANLkTi=+S_HARXj3MzsB4QiuYoPvjN7w_GrO=p4F5sV-@mail.gmail.com>	<4D583793.10409@codemonkey.ws>	<AANLkTi=xgJta=jcCfBBy+RHrh+ONs6bQ7xcouK2xNe8j@mail.gmail.com>	<4D585E3C.9010404@codemonkey.ws>	<AANLkTi=k9Q-5Qfe9JvzR1q3mKWHkR0nAZpsNCkJdPTu
 0@mail.gmail.com>	<4D599639.2030508@codemonkey.ws> <AANLkTimF9SbDECBgAcx-NEqDVrGZUz=bmojLmmrD3f2x@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	Chris Wright <chrisw@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, kvm@vger.kernel.org,
	Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org,
	Avi Kivity <avi@redhat.com>
To: Blue Swirl <blauwirbel@gmail.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-qw0-f46.google.com ([209.85.216.46]:32956 "EHLO
	mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751534Ab1BNVuk (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 14 Feb 2011 16:50:40 -0500
Received: by qwa26 with SMTP id 26so3478632qwa.19
        for <kvm@vger.kernel.org>; Mon, 14 Feb 2011 13:50:39 -0800 (PST)
In-Reply-To: <AANLkTimF9SbDECBgAcx-NEqDVrGZUz=bmojLmmrD3f2x@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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