<juha.riihim...@nokia.com> writes: > On 18.10.11 16:38 , "ext Markus Armbruster" <arm...@redhat.com> 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.
