From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj9VR-0006ig-1H for qemu-devel@nongnu.org; Wed, 20 Nov 2013 10:16:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vj9VI-000662-Hz for qemu-devel@nongnu.org; Wed, 20 Nov 2013 10:15:52 -0500 Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:56639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj9VH-00065q-QX for qemu-devel@nongnu.org; Wed, 20 Nov 2013 10:15:44 -0500 Received: by mail-wg0-f47.google.com with SMTP id y10so9087989wgg.2 for ; Wed, 20 Nov 2013 07:15:43 -0800 (PST) Date: Wed, 20 Nov 2013 16:15:38 +0100 From: Stefan Hajnoczi Message-ID: <20131120151538.GA6012@stefanha-thinkpad.muc.redhat.com> References: <1384937429-9950-1-git-send-email-cyliu@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1384937429-9950-1-git-send-email-cyliu@suse.com> Subject: Re: [Qemu-devel] [PATCH] qemu-img create: add -o nocow option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chunyan Liu Cc: kwolf@redhat.com, qemu-devel@nongnu.org On Wed, Nov 20, 2013 at 04:50:29PM +0800, Chunyan Liu wrote: > block/cow.c | 22 ++++++++++++++++++++++ > block/qcow.c | 22 ++++++++++++++++++++++ > block/qcow2.c | 22 ++++++++++++++++++++++ I think you can avoid modifying all the image formats: .bdrv_create() functions pass options to bdrv_create_file(). Therefore an image format like qcow2 does not need to parse the nocow option itself. Only raw-posix.c:.bdrv_create() needs to know about the nocow option. The exception is the block drivers that currently use open(2) directly instead of bdrv_create_file(). These should be converted to use bdrv_*() APIs instead of POSIX I/O. Please either convert them or skip them (someone will get around to fixing them eventually). > + if (nocow) { > + QEMUOptionParameter list[] = { > + { > + .name = BLOCK_OPT_NOCOW, > + .type = OPT_FLAG, > + .value.n = 1, > + .help = "No copy-on-write", > + .assigned = true > + }, > + { NULL } > + }; > + options = list; > + } This doesn't look safe to me. list[] is now out-of-scope (the compiler can reuse the stack space) and options is a dangling pointer.