[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [v7 Patch 5/5]Qemu: New struct 'BDRVReopenState' for im
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [v7 Patch 5/5]Qemu: New struct 'BDRVReopenState' for image files reopen |
Date: |
Fri, 14 Oct 2011 15:52:24 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 |
Am 14.10.2011 15:42, schrieb Supriya Kannery:
>>> + /* Use driver specific reopen() if available */
>>> + if (drv->bdrv_reopen_prepare) {
>>> + ret = drv->bdrv_reopen_prepare(bs,&rs, bdrv_flags);
>>> if (ret< 0) {
>>> - /* Reopen failed with orig and modified flags */
>>> - abort();
>>> + goto fail;
>>> }
>>> - }
>>> + if (drv->bdrv_reopen_commit) {
>>> + ret = drv->bdrv_reopen_commit(rs);
>>> + if (ret< 0) {
>>> + goto fail;
>>> + }
>>> + return 0;
>>> + }
>>
>> Pull the return 0; out one level. It would be really strange if we
>> turned a successful prepare into reopen_abort just because the driver
>> doesn't need a commit function.
>>
>> (The other consistent way would be to require that if a driver
>> implements one reopen function, it has to implement all three of them.
>> I'm fine either way.)
>>
>
> Will give flexibility to drivers, not mandating all the three functions.
Do we have a use case where it is actually possible to implement less
functions without introducing bugs?
If yes, let's keep it as it is.
> Got a question..
> In raw-posix, the three functions are implemented for file_reopen
> for now. Should this be extended to hdev, cdrom and floppy?
Yes, that would be good. And I think the same implementation can be used
for all of them.
Kevin