From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGR7w-0002Dn-Le for qemu-devel@nongnu.org; Wed, 19 Oct 2011 04:03:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGR7l-0006gP-TS for qemu-devel@nongnu.org; Wed, 19 Oct 2011 04:03:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58504) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGR7l-0006gK-9U for qemu-devel@nongnu.org; Wed, 19 Oct 2011 04:03:41 -0400 From: Markus Armbruster References: Date: Wed, 19 Oct 2011 10:03:23 +0200 In-Reply-To: (Juha Riihimaki's message of "Wed, 19 Oct 2011 06:36:18 +0000") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] hw/nand hw/onenand and read-only List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juha.Riihimaki@nokia.com Cc: peter.maydell@linaro.org, riku.voipio@iki.fi, qemu-devel@nongnu.org writes: > On 18.10.11 16:38 , "ext Markus Armbruster" wrote: > >> $ qemu-system-arm -drive if=none,file=tmp.qcow2,readonly,id=foo >>-device nand,drive=foo -kernel /dev/null >> qemu: hardware error: nand_device_init: Unsupported NAND block size. >> [...] >> >>Note that I didn't bother supplying a drive with sensible size. If I >>did, I guess I'd get nand coupled to a read-only drive. Easy enough for >>you to try :) > > Indeed, thanks ;) While I'm at it, I'll also fix the NAND init function to > return -1 instead of aborting. I'll send patches for hw/nand and > hw/onenand shortly. I'll simply make them reject read-only drives however Thanks! > both device models already support running without a drive as well by > using a memory buffer instead so it would also be possible to make them > use a read-only drive in a way that initial NAND/OneNAND contents would be > read from the drive but any changes would not be written back to the drive > and would be lost when QEMU is killed. Sounds like it could be useful, but it's not what I'd expect for "readonly". You could create a boolean device property to make memory contents transient rather than persistent. Then reject read-only drives only in persistent mode, i.e. when the property is false. Feels cleaner to me.