From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49137) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGSQL-000147-FZ for qemu-devel@nongnu.org; Wed, 19 Oct 2011 05:27:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGSQK-0000Oz-FY for qemu-devel@nongnu.org; Wed, 19 Oct 2011 05:26:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26227) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGSQJ-0000Or-U4 for qemu-devel@nongnu.org; Wed, 19 Oct 2011 05:26:56 -0400 Message-ID: <4E9E9888.2030705@redhat.com> Date: Wed, 19 Oct 2011 11:29:44 +0200 From: Kevin Wolf MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] hw/nand hw/onenand and read-only List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: riku.voipio@iki.fi, Juha.Riihimaki@nokia.com, Markus Armbruster , qemu-devel@nongnu.org Am 19.10.2011 10:46, schrieb Peter Maydell: > On 19 October 2011 09:03, Markus Armbruster wrote: >> writes: >>> 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. > > That doesn't sound very onenand/nand specific to me, though. And in fact, you already get this with -drive snapshot=on (but still leaving the drive r/w) Kevin