Re: [Qemu-devel] hw/nand hw/onenand and read-only

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> On 18 October 2011 14:38, Markus Armbruster <address@hidden> wrote:
>> Yes, that way works:
>>
>>    $ qemu-system-arm -drive if=mtd,file=tmp.qcow2,readonly
>>    qemu-system-arm: -drive if=mtd,file=tmp.qcow2,readonly: readonly not 
>> supported by this bus type
>>
>> But try this way:
>>
>>    $ qemu-system-arm -drive if=none,file=tmp.qcow2,readonly,id=foo -device 
>> nand,drive=foo
>>    Kernel image must be specified
>>
>> Grr, force it:
>>
>>    $ 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 :)
>
> Isn't this a block layer problem? It seems to be blockdev.c that
> emits the "readonly not supported" message for MTD devices, so presumably
> it ought to do so however the user sets up the device...

Only the device knows what kind of drive it needs.  The block layer can
only find out by asking the device.  There's no way to ask yet.  It
could be added to BlockDevOps, and checked in bdrv_attach_dev().

The existing readonly check in blockdev.c is a layering violation.  It
predates qdev, and it can't be cleanly extended to cover if=none.