From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Date: Tue, 15 Feb 2011 17:07:07 -0600 Message-ID: <4D5B071B.6060900@codemonkey.ws> References: <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.20305 08@codemonkey.ws> <4D59A2DA.6060705@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , kvm@vger.kernel.org, Gleb Natapov , qemu-devel@nongnu.org, Markus Armbruster , Avi Kivity To: Blue Swirl Return-path: Received: from mail-qw0-f46.google.com ([209.85.216.46]:46080 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755033Ab1BOXHZ (ORCPT ); Tue, 15 Feb 2011 18:07:25 -0500 Received: by qwa26 with SMTP id 26so571793qwa.19 for ; Tue, 15 Feb 2011 15:07:25 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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. 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. >> 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. >> > 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 Yeah, I'm not disagreeing at all. Ignoring the fact that modern uarts are implemented in a super i/o chip, it's same chip whether it's soldered directly on a board with direct connections to a CPU bus or whether it's exposed on the ISA bus. Regards, Anthony Liguori > but otherwise I fear this > would only increase complexity with no gain. > >