From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTZJ9-0003QZ-9g for qemu-devel@nongnu.org; Mon, 06 Jun 2011 08:53:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTZJ7-00008g-B1 for qemu-devel@nongnu.org; Mon, 06 Jun 2011 08:53:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTZJ6-00008U-OA for qemu-devel@nongnu.org; Mon, 06 Jun 2011 08:53:25 -0400 Message-ID: <4DECCE6C.9010103@redhat.com> Date: Mon, 06 Jun 2011 14:56:12 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1305808412-16994-1-git-send-email-kwolf@redhat.com> <1305808412-16994-6-git-send-email-kwolf@redhat.com> <20110526181208.46aba2ae@doriath> <20110601104456.5469329b@doriath> <4DE64690.8020500@redhat.com> <4DEC98FF.5010605@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 05/18] ide: Turn debug messages into assertions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, Luiz Capitulino Am 06.06.2011 13:57, schrieb Markus Armbruster: >>>> Not sure what's the best way of fixing this. Maybe just ignoring >>>> -snapshot for read-only block devices? >>> >>> Why not, the combination is pointless. >> >> It could start making a difference in some obscure combinations. Imagine >> a read-only image with a backing file, -snapshot and the 'commit' >> monitor command. >> >> Sounds pretty insane, but I wouldn't bet that people aren't using it... > > People try all kinds of insane things. The question is whether we can > change it anyway. We have a backing file chain like base <- cow [<- tmp], and the drive is read-only. Currently, 'commit' means that tmp is committed to cow (i.e. nothing happens because it's read-only). After changing it, we would commit the content of cow to base and possibly corrupt other images that are based on base. We can hope that nobody would be hit by it in practice, but it's not a change I'd feel very comfortable about. >>>> Or we could try and forward the >>>> eject request to the backing file if the format driver doesn't handle it. >>> >>> For what it's worth, the "raw" driver forwards manually. >> >> Yeah, but copying that into each driver probably isn't the right thing >> to do. > > I didn't mean to hold up the "raw" driver as a shining example of how to > do stuff. > >> For a generic implementation we could probably first try the >> driver itself, if it returns -ENOTSUP we try the protocol, and if that >> returns -ENOTSUP, too, we ask the backing file driver. > > I don't want to start another "format vs. protocol" semantic war, just > point out that the general case is a tree of block drivers, and a > general rule for passing eject up the tree better covers that. > > The current block.c provides for binary trees (bs->file and > bs->backing_hd). When we discussed blockdev_add, we came up with much > wilder trees. I didn't mean to imply that you suggested raw was a shining example. However, if we're going for the wild trees (or even graphs), there's no simple option of doing it in generic code any more. Backing files and protocols (for lack of a better term) are special in the tree because they are a concept that the block layer knows. For everything else the least we need is a hint from the block driver. In any case passing up the tree means that you need to decide which child is the one to try first, or if there are children to which it shouldn't be passed at all. Kevin