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
