From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch] kvmctl.c: allow custom memory setup. Date: Thu, 18 Oct 2007 14:34:04 +0200 Message-ID: <471752BC.90600@qumranet.com> References: <470C8D28.2060408@qumranet.com> <470F2806.8090902@redhat.com> <4710701C.2040200@qumranet.com> <47134476.1050609@redhat.com> <47134857.9030102@redhat.com> <1192446374.6578.0.camel@izike-woof.qumranet.com> <47134BC0.1000008@redhat.com> <1192447442.6911.5.camel@izike-woof.qumranet.com> <47135284.1060106@redhat.com> <4715DEFC.8010507@redhat.com> <471690D2.2060204@qumranet.com> <47170D95.1050603@redhat.com> <471714FC.6050703@qumranet.com> <47173300.70907@redhat.com> <1192703432.3175.18.camel@izike-woof.qumranet.com> <471737E8.6000708@qumranet.com> <47173E21.3010502@redhat.com> <471741D1.7000500@qumranet.com> <47175088.7000507@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Gerd Hoffmann Return-path: In-Reply-To: <47175088.7000507-H+wXaHxf7aLQT0dZR+AlfA@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 Gerd Hoffmann wrote: > Hi, > > >> Break it. It has just one user, our qemu, which is included in the same >> package. >> > > No, I'm hacking up one more user ;) > > Nice. What will it do? > But maybe I'm better off shipping a private copy of kvmctl.c as long as > the library interface isn't finalized yet and subject to change. > > Yes. Patches to improve libkvm's interface so we can decouple it from qemu will be most welcome. >>> Thats why I went the route to additionally split the job kvm_create() >>> does into multiple, individually callable pieces. So I can first create >>> the vm, then create my custom memory slots (instead of the standard >>> setup built by kvm_create_userspace_memory()), then create the vcpu. >>> >>> >> That's exactly what's needed. >> >> The patch looks good, except that I wouldn't export >> kvm_create_default_phys_mem(). >> > > Fine with me. If you one uses the splitted versions, then for creating > a non-default memory layout, so there is no point in exporting that one. > > Should I send an updated patch or do you just drop these lines when merging? > Please send a rebased and retested patch. -- 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/