From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs Date: Mon, 29 Nov 2010 12:52:29 +0200 Message-ID: <4CF385ED.8030700@redhat.com> 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> <20101128115921.GB11685@redhat.com> <4CF252DA.1050303@redhat.com> <20101128135749.GB12874@redhat.com> <4CF2687F.3000306@redhat.com> <20101128165758.GE12874@redhat.com> <4CF370E4.5050903@redhat.com> <20101129104736.GA26738@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Marcelo Tosatti , kvm@vger.kernel.org To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:10509 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752365Ab0K2Kwg (ORCPT ); Mon, 29 Nov 2010 05:52:36 -0500 In-Reply-To: <20101129104736.GA26738@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/29/2010 12:47 PM, Michael S. Tsirkin wrote: > On Mon, Nov 29, 2010 at 11:22:44AM +0200, Avi Kivity wrote: > > >> No need for an additional toolchain. > > > > > >It's a feature :) This way you are not forced to rewrite all code each > > >time you realize you need an extra check, and checks can be added > > >gradually without breaking build. > > > > You can see that user_ptr<> is not just for the checks, it adds > > functionality (sizeof-less copy_from and copy_to). That's usually > > the case. If there's something you must not do because of some > > rule, there's also something you want to do, and those become member > > functions. > > > > In C++ you could also introduce user_ptr<> gradually, it won't break > > anything. > > Yes but in > void foo(void *p) { > bar(p); > } > both foo and bar must be converted. No. You can convert from user_ptr<> to __user * and back. > > >Sparse has some advantages: it makes the contract obvious so you clearly > > >see it's a pointer and know ->, [], + will work, * and<< will not. > > > > I don't really see how you can tell this from __user. > > I can tell this is a pointer from T *foo :), and I can tell > it has some attribute. > > > You have to > > look up the definition. For user_ptr<>, the definition is actually > > available. > > The definition for __user is also available: > #ifdef __CHECKER__ > # define __user __attribute__((noderef, address_space(1))) > #else > # define __user > #endif > > Which is a very transparent way to say: this is just a checker > attribute, it does not affect actual code. Can you tell you must not dereference it? > With a template we go 'I have overridden + but compiler should > optimize it back to original'. Note the should :) We do this in C all the time with pte_t and lots of inlines. > > Do a 'git grep hash' for examples of duplication. > > I see. Don't know enough about tcg to fix unfortunately, but > the logic is different: e.g. sparc opcode table is completely > static, translation cache is dynamic, jump cache has > static size but dynamic content, qdict could do > with linear lookups just as well. So it could > just be different optimization strategies. The default is duplication. With C++ your default is tr1::unordered_map<> and you can optimize it later if you like. -- error compiling committee.c: too many arguments to function