From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 00 of 27] Refactor libkvm code Phase 1 Date: Thu, 01 Nov 2007 14:52:49 +0200 Message-ID: <4729CC21.5050004@qumranet.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, kvm-ppc-devel To: Jerone Young Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Jerone Young wrote: > Kaniciwa! > I am here to once again bring great honorable patches to refactor > libkvm x86 code. Patches that I sent in the past for this really took > the wrong approach, and also many variables that I was splitting out actually > could be shared amongst many architectures. > > This is the first phase as much of the code is tightly written for x86 > but can be reused by other archs, it's just a matter of an agreed upon method. > Also since there are about 27 of these lets get through these before moving > through more. > > Apart from the namespace issues (don't export library-private functions, start names with kvm_) this looks good. Please make sure that it's bisect friendly (should compile as each patch is applied in sequence). With git I use something like for rev in $(git rev-list foo..bar); do git checkout $rev; make; done to make sure that's the case. -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/