From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAG9S-0006XU-8W for qemu-devel@nongnu.org; Mon, 03 Feb 2014 04:49:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAG9M-0008Hd-3v for qemu-devel@nongnu.org; Mon, 03 Feb 2014 04:49:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:64706) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAG9L-0008HY-R8 for qemu-devel@nongnu.org; Mon, 03 Feb 2014 04:49:08 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s139n6MO020206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 3 Feb 2014 04:49:06 -0500 Date: Mon, 3 Feb 2014 10:49:04 +0100 From: Kevin Wolf Message-ID: <20140203094904.GE3643@dhcp-200-207.str.redhat.com> References: <1390762963-25538-1-git-send-email-mreitz@redhat.com> <1390762963-25538-2-git-send-email-mreitz@redhat.com> <20140129115030.GE2726@dhcp-200-207.str.redhat.com> <52EC0266.9040407@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52EC0266.9040407@redhat.com> Subject: Re: [Qemu-devel] [PATCH 01/10] block: Change BDS parameter of bdrv_open() to ** List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: qemu-devel@nongnu.org, Stefan Hajnoczi Am 31.01.2014 um 21:07 hat Max Reitz geschrieben: > >So in summary, it looks technically correct, but I'm not sure about > >maintainability. If the problems are only for this intermediate state, > >I'm okay with leaving them as they are, but otherwise we should try and > >figure out something. > > You're right in that bdrv_open should always create a new BDS and > new BDS should always be created through bdrv_open; but right now, > there are some places in the code (such as blockdev_init()) which I > was just afraid of touching as they seemed to heavily rely on being > able to separate those two steps. Sure, there's a good reason why we work in incremental steps. This is a huge conversion of infrastructure and trying to change it all at once never worked out. We shouldn't worry too much about ugly intermediate states as long as we're sure that they are really just intermediate. Kevin