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: Mon, 29 Nov 2010 07:44:38 -0600 Message-ID: <4CF3AE46.1050102@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> <20101128122737.GC11685@redhat.com> <4CF2D1F2.8030309@codemonkey.ws> <20101128222847.GA19081@redhat.com> <4CF2E225.7070301@codemonkey.ws> <20101129080421.GA25452@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: "Michael S. Tsirkin" Return-path: Received: from mail-gx0-f174.google.com ([209.85.161.174]:59684 "EHLO mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753899Ab0K2Nok (ORCPT ); Mon, 29 Nov 2010 08:44:40 -0500 Received: by gxk1 with SMTP id 1so5992gxk.19 for ; Mon, 29 Nov 2010 05:44:40 -0800 (PST) In-Reply-To: <20101129080421.GA25452@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/29/2010 02:04 AM, Michael S. Tsirkin wrote: > On Sun, Nov 28, 2010 at 05:13:41PM -0600, Anthony Liguori wrote: > >> On 11/28/2010 04:28 PM, Michael S. Tsirkin wrote: >> >>> >>>> But rather need to use ugly factory functions with all sorts of >>>> DO_UPCAST. This is really unfriendly especially for writing test >>>> cases. >>>> >>> Yes, I agree. Just moving memory allocation out of there >>> will fix most of the ugliness. >>> >> So here's a short list of things I've been working on that I don't >> believe have nice implementations in C. >> >> 1) Factories with string based parameters with natural constructor >> arguments. >> > This was the only item, right? So in fact, this is needed as part of > configuration file/command line/monitor parser. > I really see it more as an API interface. I think the best long term architecture for QEMU is where qemu is launched as essentially a daemon and is manipulated via an RPC interface to create an initial device model, etc. > IMHO, this really should be separate from the device model. > The fact that qdev currently mixes the device model > with argument parsing is bad IMO. So we ended up with > saying > .driver = "PCI" > in hw/pc_piix.c instead of an instance of the structure. > There's no compile-time check that the correct string > is used and that is pretty bad IMO. > Indeed. > Yes, this makes it easier to add new properties, but making it easy is > exactly the wrong thing to do because we really have to support such > properties forever. > One advantage of having a factory and the objects in a single place is that the factory is the long term supported interface and the objects can evolve in a more natural fashion. > So how about a compromise: libqemu written in C, with APIs that should > not deal with string parsing at all, and should above all else make > sense: > i8254_init_drift_mode > i8254_init_catchup > > net_set_link_up > net_set_link_down > > (and it really needs to be C for portability: so that management > written in C can use it). > This API should be properly versioned, with a backwards compatibility > story, and we should be careful about adding interfaces there. > > On top of this you can have a management interface written in > any other language, and have that deal with string parsing. > I still dislike the idea of implementing an object system in C. Besides reinventing vtables, we'll have to also reinvent RTTI to allow for safe upcasting (which is unavoidable). But really, let's defer this discussion for when patches are available. I understand your objections but I'm pretty convinced that the code will speak for itself when it's ready. Regards, Anthony Liguori