From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: RFC/patch: a very trivial patch towards portability V2.1 Date: Wed, 10 Oct 2007 15:21:59 +0200 Message-ID: <470CD1F7.1030400@qumranet.com> References: <1191946167.7292.3.camel@cotte.boeblingen.de.ibm.com> <1192019827.17745.9.camel@cotte.boeblingen.de.ibm.com> <1192020355.17877.4.camel@cotte.boeblingen.de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" To: Carsten Otte Return-path: In-Reply-To: <1192020355.17877.4.camel-WIxn4w2hgUz3YA32ykw5MLlKpX0K8NHHQQ4Iyu8u01E@public.gmane.org> 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 Carsten Otte wrote: > Christian Borntraeger pointed out that Avi requested to rename kvm_x86.c > to x86.c. The patch below is the same as V2, but the files kvm_x86.[ch] > have been renamed to x86.[ch], and the #includes have been updated. > > signed-off-by: Carsten Otte > --- > Index: kvm/drivers/kvm/kvm.h > =================================================================== > --- kvm.orig/drivers/kvm/kvm.h 2007-10-10 12:42:21.000000000 +0200 > +++ kvm/drivers/kvm/kvm.h 2007-10-10 14:12:30.000000000 +0200 > @@ -653,6 +653,11 @@ > > int kvm_fix_hypercall(struct kvm_vcpu *vcpu); > > +long kvm_arch_dev_ioctl(struct file *, > + unsigned int, unsigned long); > +__init void kvm_arch_init(void); > +long kvm_arch_check_extension(int); > Argument names in prototypes please. > case KVM_CHECK_EXTENSION: { > int ext = (long)argp; > > - switch (ext) { > - case KVM_CAP_IRQCHIP: > - case KVM_CAP_HLT: > - case KVM_CAP_MMU_SHADOW_CACHE_CONTROL: > - case KVM_CAP_USER_MEMORY: > - r = 1; > - break; > - default: > - r = 0; > - break; > - } > + r = kvm_arch_check_extension(ext); > break; > > Reflecting some more, do we want different API availablility for different archs? We can make this generic, and ignore arch-specific extensions. But on the other hand, things like KVM_CAP_IRQCHIP _are_ applicable to powerpc, but may not be implemented from day 1... should we do case KVM_CAP_IRQCHIP: return KVM_ARCH_HAS_IRQCHIP; ? -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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/