From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49679 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PpTzT-0001Fw-Dg for qemu-devel@nongnu.org; Tue, 15 Feb 2011 18:07:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PpTzS-0000dq-2U for qemu-devel@nongnu.org; Tue, 15 Feb 2011 18:07:27 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:42716) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PpTzR-0000dl-U5 for qemu-devel@nongnu.org; Tue, 15 Feb 2011 18:07:26 -0500 Received: by qwk4 with SMTP id 4so589495qwk.4 for ; Tue, 15 Feb 2011 15:07:25 -0800 (PST) Message-ID: <4D5B071B.6060900@codemonkey.ws> Date: Tue, 15 Feb 2011 17:07:07 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 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.2030508@codemonkey.ws> <4D59A2DA.6060705@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Chris Wright , kvm@vger.kernel.org, Gleb Natapov , Markus Armbruster , qemu-devel@nongnu.org, Avi Kivity 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. > >