From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs Date: Wed, 24 Nov 2010 12:17:00 -0600 Message-ID: <4CED569C.7030008@codemonkey.ws> References: <1290595933-13122-1-git-send-email-avi@redhat.com> <1290595933-13122-3-git-send-email-avi@redhat.com> <50DD1E97-0ECD-41E6-B6F8-1D78AA4A4876@suse.de> <4CED2416.1040102@codemonkey.ws> <20101124154006.GE15111@redhat.com> <4CED344B.3030000@codemonkey.ws> <20101124161204.GF15111@redhat.com> <4CED3FE5.4000801@codemonkey.ws> <20101124173345.GI20014@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Avi Kivity , Marcelo Tosatti , kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mail-pz0-f46.google.com ([209.85.210.46]:59095 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752656Ab0KXSRh (ORCPT ); Wed, 24 Nov 2010 13:17:37 -0500 Received: by pzk6 with SMTP id 6so9143pzk.19 for ; Wed, 24 Nov 2010 10:17:37 -0800 (PST) In-Reply-To: <20101124173345.GI20014@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/24/2010 11:33 AM, Gleb Natapov wrote: > On Wed, Nov 24, 2010 at 10:40:05AM -0600, Anthony Liguori wrote: > >> On 11/24/2010 10:12 AM, Gleb Natapov wrote: >> >>> >>>> Why would we specify a PIIX3 device based on a configuration file? >>>> There is only one PIIX3 device in the world. I don't see a lot of >>>> need to create arbitrary types of devices. >>>> >>>> >>> Why deny this flexibility from those who need it for modelling >>> different HW? Besides, as I said, PIIX3 is ISA bridge and this >>> is what class should implement. We have fw_cfg on ISA bus too >>> which does not exits on real HW and we may want to have other >>> devices. We should be able to add them without changing PIIX3 >>> class. >>> >> Because this flexibility is a misfeature. It's something that noone >> actually uses and I've never seen anyone ask to have. >> >> It introduces a PC-centric view of the world where you artificially >> make a bunch of devices have bus specific logic that they really >> don't have. >> >> > Actually other way around. Non PC embedded systems are those that needs > this flexibility the most. > > > >> If you want to go down this route, the right approach to take is to >> make a separate IsaMc161818a device that has a Mc16818a device with >> a has-a relation (i.e. composition). >> > There are many devices in qemu that accessed via isa bus on PCI and via > MMIO in other archs, so the thing you propose here is logical and > actually implemented this way in qdev. > Except the Mc16818a device is not a qdev device. >> But I don't see the point. Just stick the Mc16818a device in the >> PIIX3 via composition as it exists on normal hardware and call it a >> day. >> > Shortcuts, shortcuts. I think this is how qemu was written initially. > "Lets put this here and call it a day!" > Implementing something correctly in the way that hardware does is not a short cut. >> Right, and real HW does composition in the PIIX3 device. So let's >> not regret making everything an ISA device later. >> >> > You design by packaging not functionality? > No, if you want the ability to remove devices from the PIIX3, fine, but don't call them ISA devices just for the sake of it. >>> Garbage collection can be done >>> while vcpu executes guest code and in proper implementation vcpu thread >>> should execute device model code for a very brief time and do not sleep >>> there. All this makes me think that garbage collection shouldn't be a >>> big issue for kvm userspace. >>> >> But I don't see the point. If you look at my repository, there's >> > The point is that C++ is ugly language. The short code Avi sent remind > me perl (aka line noise). It is almost impossible to parse it into > what code it actually does. Most symbols are there for C++ syntax not > functionality. > I'm using C++ to understand how to make a correct design model. The C++ part is only 10% of what I care about. I agree that Avi's example is not a strong justification for C++ and I also agree that it's uglier than the same implementation in C. >> very few memory allocations. This is largely due to the fact that I >> don't overly abstract busses and rely on simple composition where >> appropriate. >> > I am not sure you can write useful program with few memory allocations. > Ultimately, you're allocating the same amount of memory, but in fewer steps (because of static composition). Regards, Anthony Liguori >> Plus, with tr1::smart_pointers, you can be leak free without every >> worrying about explicit freeing. There are, of course, >> possibilities of having circular references but it's not too hard to >> avoid that in practice. >> >> > -- > Gleb. >