From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: RFC/patch: a very trivial patch towards portability Date: Tue, 09 Oct 2007 18:17:14 +0200 Message-ID: <470BA98A.8090900@qumranet.com> References: <1191946167.7292.3.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: <1191946167.7292.3.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: > We've seen various big patches regarding portability from Christian and > Xianto, but none was merged to date. Maintaining a large patch set on > top of a quickly moving code base is painful. > I thought it might be cool to try to throw trivial patches at Avi that > obviously don't break things and push towards portability. In case this > succeeds I'll keep throwing in trivial patches until we've split > everything proper. > This patch splits kvm_dev_ioctl into architecture independent and > architecture dependent ioctls. Those that are arch independent remain in > kvm_main.c, others are implemented by kvm_arch_dev_ioctl() in kvm_x86.c. > A header file named kvm_arch.h is being introduced that contains > prototypes for funtions in kvm_x86.c. > > Comments? Is this a preferable approach? What needs to be done > different? > > Small, reviewable, posted patches are definitely the best way forward. > - 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: > - r = 1; > - break; > - default: > - r = 0; > - break; > - } > - break; > - } > CHECK_EXTENSION is hopefully a generic mechanism (even if the some of the actual extensions are not). So there should be a switch in common code for the common extensions, and the default: target should call kvm_arch_check_extension() for further processing. > - case KVM_GET_VCPU_MMAP_SIZE: > - r = -EINVAL; > - if (arg) > - goto out; > - r = 2 * PAGE_SIZE; > - break; > I would think this is generic too? Isn't s390 interested in passing information to userspace via a mmap()ed region? Note that mmio data is passed via that region. > > Index: kvm/drivers/kvm/kvm_x86.c > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ kvm/drivers/kvm/kvm_x86.c 2007-10-09 16:47:55.000000000 +0200 > x86.c -- 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/