From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFRyR-0002sY-IH for qemu-devel@nongnu.org; Mon, 17 Feb 2014 12:27:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFRyI-00064B-7K for qemu-devel@nongnu.org; Mon, 17 Feb 2014 12:27:19 -0500 Received: from mail-ea0-x229.google.com ([2a00:1450:4013:c01::229]:42635) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFRyI-00063h-1C for qemu-devel@nongnu.org; Mon, 17 Feb 2014 12:27:10 -0500 Received: by mail-ea0-f169.google.com with SMTP id h10so7448410eak.28 for ; Mon, 17 Feb 2014 09:27:09 -0800 (PST) Sender: Paolo Bonzini Message-ID: <53024667.2060103@redhat.com> Date: Mon, 17 Feb 2014 18:27:03 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1392293009-13812-1-git-send-email-a.motakis@virtualopensystems.com> <1392293009-13812-2-git-send-email-a.motakis@virtualopensystems.com> <5446ebb6-aeff-48dc-b97e-b9a1bfcdfb68@email.android.com> <53014CF5.8070600@redhat.com> <20140217075603.GA18334@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v8 01/17] Convert -mem-path to QemuOpts and add prealloc and share properties List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Antonios Motakis , "Michael S. Tsirkin" Cc: Peter Maydell , snabb-devel@googlegroups.com, Anthony Liguori , Juan Quintela , Michael Tokarev , Markus Armbruster , Nikolay Nikolaev , qemu-devel qemu-devel , Alexander Graf , Stefan Hajnoczi , Luke Gorrie , VirtualOpenSystems Technical Team , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Richard Henderson Il 17/02/2014 14:04, Antonios Motakis ha scritto: > > Hmm in that case, let's not add prealloc as a property here. > Stick to existing flag for that, this way we don't need > to support 3 ways to do this. > > > We'll remove the prealloc property then for the next version. > > Otherwise, I wonder if the long term memdev discussion can impose > additional constraints on our current implementation. It seems to me > that this shouldn't be the case, right? No, on the contrary it will be more flexible. Just this patch will be dropped and a different command-line will be required on your part. Paolo