From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIef4-0005rr-DQ for qemu-devel@nongnu.org; Tue, 03 Feb 2015 09:41:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIef0-0005ws-Eb for qemu-devel@nongnu.org; Tue, 03 Feb 2015 09:41:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIef0-0005wX-79 for qemu-devel@nongnu.org; Tue, 03 Feb 2015 09:41:02 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t13Ef0n3015187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 3 Feb 2015 09:41:01 -0500 Date: Tue, 3 Feb 2015 15:40:58 +0100 From: Kevin Wolf Message-ID: <20150203144058.GG4488@noname.redhat.com> References: <1411588107-4275-1-git-send-email-mreitz@redhat.com> <20150203093205.GB4488@noname.redhat.com> <54D0D1B8.4000500@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D0D1B8.4000500@redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/4] block: Drop BDS.filename List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: qemu-devel@nongnu.org, Stefan Hajnoczi Am 03.02.2015 um 14:48 hat Max Reitz geschrieben: > On 2015-02-03 at 04:32, Kevin Wolf wrote: > >Am 24.09.2014 um 21:48 hat Max Reitz geschrieben: > >>The BDS filename field is generally only used when opening disk images > >>or emitting error or warning messages, the only exception to this rule > >>is the map command of qemu-img. However, using exact_filename there > >>instead should not be a problem. Therefore, we can drop the filename > >>field from the BlockDriverState and use a function instead which builds > >>the filename from scratch when called. > >> > >>This is slower than reading a static char array but the problem of that > >>static array is that it may become obsolete due to changes in any > >>BlockDriverState or in the BDS graph. Using a function which rebuilds > >>the filename every time it is called resolves this problem. > >> > >>The disadvantage of worse performance is negligible, on the other hand. > >>After patch 2 of this series, which replaces some queries of > >>BDS.filename by reads from somewhere else (mostly BDS.exact_filename), > >>the filename field is only used when a disk image is opened or some > >>message should be emitted, both of which cases do not suffer from the > >>performance hit. > >Surprisingly (or not), this one needs rebasing. > > Well... > > >I tried it and it doesn't look too hard, but it's a little bit more than > >what I'm comfortable with doing while applying a series. > > I admire your courage, but I'm not sure whether this series is ready > for being applied at all. First we (or I) will have to look into how > users like libvirt which identify a BDS based on the filename can > break from applying this series. Well, I haven't reviewed it, so I can't tell. It didn't have a (Self-)NACK and it's still on your list of to-be-merged patches, so I took a look. You're talking about courage - but I just wasn't courageous enough yet to attack your larger series... ;-) Kevin