From: Kevin Wolf <kwolf@redhat.com>
To: supriyak@linux.vnet.ibm.com
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
qemu-devel@nongnu.org, Christoph Hellwig <hch@lst.de>
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 [thread overview]
Message-ID: <4E983E98.6040202@redhat.com> (raw)
In-Reply-To: <4E983C51.8010008@linux.vnet.ibm.com>
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
next prev parent reply other threads:[~2011-10-14 13:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-11 3:10 [Qemu-devel] [v7 Patch 0/5]Qemu: Host pagecache setting from cmdline and monitor Supriya Kannery
2011-10-11 3:10 ` [Qemu-devel] [v7 Patch 1/5]Qemu: Enhance "info block" to display host cache setting Supriya Kannery
2011-10-12 14:17 ` Kevin Wolf
2011-10-14 10:47 ` Supriya Kannery
2011-10-11 3:11 ` [Qemu-devel] [v7 Patch 2/5]Qemu: Error classes for file reopen and data sync failure Supriya Kannery
2011-10-11 3:11 ` [Qemu-devel] [v7 Patch 3/5]Qemu: Cmd "block_set_hostcache" for dynamic cache change Supriya Kannery
2011-10-11 3:11 ` [Qemu-devel] [v7 Patch 4/5]Qemu: Add commandline -drive option 'hostcache' Supriya Kannery
2011-10-12 14:30 ` Kevin Wolf
2011-10-14 11:19 ` Supriya Kannery
2011-10-14 11:26 ` Kevin Wolf
2011-10-11 3:11 ` [Qemu-devel] [v7 Patch 5/5]Qemu: New struct 'BDRVReopenState' for image files reopen Supriya Kannery
2011-10-12 14:55 ` Kevin Wolf
2011-10-14 13:42 ` Supriya Kannery
2011-10-14 13:52 ` Kevin Wolf [this message]
2011-10-14 11:13 ` Stefan Hajnoczi
2011-10-14 13:45 ` Supriya Kannery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E983E98.6040202@redhat.com \
--to=kwolf@redhat.com \
--cc=hch@lst.de \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=supriyak@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).