From mboxrd@z Thu Jan 1 00:00:00 1970 From: Blue Swirl Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Date: Tue, 15 Feb 2011 19:11:24 +0200 Message-ID: References: <4D52F20A.7070009@codemonkey.ws> <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> <4D57F96B.7010004@codemonkey.ws> <4D583793.10409@codemonkey.ws> <4D585E3C.9010404@codemonkey.ws> <4D599639.2030508@codemonkey.ws> <4D59A2DA.6060705@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Chris Wright , kvm@vger.kernel.org, Gleb Natapov , Markus Armbruster , qemu-devel@nongnu.org, Avi Kivity To: Anthony Liguori Return-path: Received: from mail-gy0-f174.google.com ([209.85.160.174]:41637 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752579Ab1BORLp convert rfc822-to-8bit (ORCPT ); Tue, 15 Feb 2011 12:11:45 -0500 Received: by gyb11 with SMTP id 11so183572gyb.19 for ; Tue, 15 Feb 2011 09:11:44 -0800 (PST) In-Reply-To: <4D59A2DA.6060705@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori 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. =C2=A0For our own sanity, I think we sh= ould 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. =C2=A0We can = also create > a MMIO version of SerialState although there's no direct structure th= at > wraps that. > > Ideally, SerialState would be a proper qdev device that is embedded i= n both > ISASerialState and MMIOSerialState (or pick a better name). =C2=A0inf= o 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38016 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PpORH-0004Li-62 for qemu-devel@nongnu.org; Tue, 15 Feb 2011 12:11:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PpORF-0002Rl-Nk for qemu-devel@nongnu.org; Tue, 15 Feb 2011 12:11:46 -0500 Received: from mail-yw0-f45.google.com ([209.85.213.45]:64594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PpORF-0002Rh-Iw for qemu-devel@nongnu.org; Tue, 15 Feb 2011 12:11:45 -0500 Received: by ywa8 with SMTP id 8so206426ywa.4 for ; Tue, 15 Feb 2011 09:11:44 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D59A2DA.6060705@codemonkey.ws> References: <4D52F20A.7070009@codemonkey.ws> <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> <4D57F96B.7010004@codemonkey.ws> <4D583793.10409@codemonkey.ws> <4D585E3C.9010404@codemonkey.ws> <4D599639.2030508@codemonkey.ws> <4D59A2DA.6060705@codemonkey.ws> From: Blue Swirl Date: Tue, 15 Feb 2011 19:11:24 +0200 Message-ID: Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, Gleb Natapov , qemu-devel@nongnu.org, Markus Armbruster , Avi Kivity On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori w= rote: > 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 us= er > to directly instantiate a device. > > Any device we expose to the user through -device needs to maintain a > compatible interface forever. =C2=A0For 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 expo= se > 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. =C2=A0We 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 bo= th > ISASerialState and MMIOSerialState (or pick a better name). =C2=A0info qt= ree > 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.