From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxRQt-0002xK-3s for qemu-devel@nongnu.org; Thu, 01 Apr 2010 16:56:07 -0400 Received: from [140.186.70.92] (port=49149 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxRQq-0002vH-Hb for qemu-devel@nongnu.org; Thu, 01 Apr 2010 16:56:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxRQd-0007ds-GM for qemu-devel@nongnu.org; Thu, 01 Apr 2010 16:55:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35499) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NxRQd-0007dd-68 for qemu-devel@nongnu.org; Thu, 01 Apr 2010 16:55:51 -0400 Date: Thu, 1 Apr 2010 17:55:42 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH] Add qerror message if the 'change' target filename can't be opened Message-ID: <20100401175542.5802f704@redhat.com> In-Reply-To: <4BB4F096.10302@redhat.com> References: <20100325143258.GS27260@us.ibm.com> <20100401151551.443ba961@redhat.com> <20100401152233.71e778ed@redhat.com> <4BB4F096.10302@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Ryan Harper , qemu-devel@nongnu.org, Juan Quintela On Thu, 01 Apr 2010 21:14:30 +0200 Kevin Wolf wrote: > Am 01.04.2010 20:22, schrieb Luiz Capitulino: > > On Thu, 1 Apr 2010 15:15:51 -0300 > > Luiz Capitulino wrote: > > > >> On Thu, 25 Mar 2010 09:32:58 -0500 > >> Ryan Harper wrote: > >> > >>> Currently when using the change command to switch the file in the cd drive > >>> the command doesn't complain if the file doesn't exit or can't be opened > >>> and the drive keeps the existing image. This patch adds a qerror_report > >>> call to print a message out indicating the failure. This error message > >>> can be used to catch failures. > >> > >> Looks good to me, but it doesn't keep the existing image, it will silently > >> eject it instead. > > > > And, thinking more about it this seems the wrong behavior to me, if it > > fails to open the file, it should not touch the current one. > > > > Am I right, Kevin? > > Well, it's a monitor command. I guess its meaning has never been clearly > defined, so I tend to say there is no right or wrong. From a user > perspective, intuitively I would expect that it succeeds completely or > maintains the old state, so yes. Yes and I'd expect the same from a QMP perspective. > However, I don't think it's fixable that easy. You obviously need to > close the image before you can open it. And reopening the image in case > of failure - well, we just had this discussion and I'm sure Juan wants > to comment on it... > > It's a case that we should consider if/when we reorganize bdrv_open. The > "bdrv_close, but without closing the fd" thing doesn't work out here > because we need to reuse the same bs. Or maybe open a different bs first > and then copy things over. Could actually work this way. Yeah, I looked there and realized it wasn't easy but this solution looks good.