qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]