[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V2 10/10] hw/sd.c: introduce SD card "image" pro
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH V2 10/10] hw/sd.c: introduce SD card "image" property and allow SD hot-insert |
Date: |
Tue, 10 Apr 2012 08:33:56 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
Il 09/04/2012 16:30, Igor Mitsyanko ha scritto:
>>> +
>>> + if (error_is_set(errp)) {
>>> + return;
>>> + }
>>> +
>>> + if (sd->bdrv) {
>>> + qmp_change_blockdev(bdrv_get_device_name(sd->bdrv), new_image,
>>> + false, NULL, errp);
>>> + } else {
>>> + DriveInfo *di;
>>> + QemuOpts *opts = drive_add(IF_SD, sd->if_idx, new_image, "");
>> I think this should simply take a drive name and pass it to
>> bdrv_get_device_name.
> Did you mean bdrv_find()? I can't use it here, BlockDriverState doesn't
> exist yet, I need to create it first with drive_add.
Yes, that's the point. :)
>> The drive_add/drive_init should be done
>> separately with the drive_add monitor command, like
>>
>> drive_add 0 file=foo.img,if=none,id=bar
>>
> So you're saying we need to use two commands to insert a new virtual SD
> card: first we need to create a BlockDriverState with specified device_name
> and then with second command we associate SD card with previously created
> BlockDriverState?
> I kind of like another approach, when we can just set filename as SD
> card's property and BlockDriverState will be automatically created and
> connected to this SD card's state.
But then you cannot set any property like the format, the caching mode,
etc. Especially with the default of cache=writethrough it may be *very*
slow.
> And when we want to eject card from virtual slot, we set SDCard::eject
> property to true and then associated BlockDriverState is dereferenced
> and freed automatically.
That's possible, though I'm not sure why the normal eject/change
commands cannot work here.
>> There is a problem here however. QOM commands are HMP only, and
>> drive_add is QMP only. I think that blocking drive_add in QMP is
>> perfect being the enemy of good. Alternatively, however, adding the QOM
>> property commands to HMP would also make sense.
> I don't understand, is it some kind of conceptual restriction?
No, it's just that nobody implemented them.
Paolo
- [Qemu-devel] [PATCH V2 03/10] hw/sd.c: make sd_dataready() return bool, (continued)
[Qemu-devel] [PATCH V2 08/10] SD card: introduce "spi_mode" property for SD card objects, Igor Mitsyanko, 2012/04/05
[Qemu-devel] [PATCH V2 06/10] hw/sd.c: convert to QOM object, Igor Mitsyanko, 2012/04/05
[Qemu-devel] [PATCH V2 02/10] hw/sd.c: convert binary variables to bool, Igor Mitsyanko, 2012/04/05
[Qemu-devel] [PATCH V2 04/10] hw/sd.c: make sd_wp_addr() return bool, Igor Mitsyanko, 2012/04/05
[Qemu-devel] [PATCH V2 09/10] SD card: make SD card a child of host controller, Igor Mitsyanko, 2012/04/05