From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55418)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1b3hdY-000487-D6
	for qemu-devel@nongnu.org; Fri, 20 May 2016 06:26:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1b3hdW-0006DJ-EN
	for qemu-devel@nongnu.org; Fri, 20 May 2016 06:26:31 -0400
Date: Fri, 20 May 2016 12:26:22 +0200
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20160520102622.GF4861@noname.redhat.com>
References: <1463671329-22655-1-git-send-email-kwolf@redhat.com>
	<1463671329-22655-22-git-send-email-kwolf@redhat.com>
	<6e34bd03-65d6-ceab-be3b-0e24450ed006@redhat.com>
	<20160520080549.GB4861@noname.redhat.com>
	<20160520081017.GC4861@noname.redhat.com>
	<03d90284-3538-d57f-dd93-920b6de227c8@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <03d90284-3538-d57f-dd93-920b6de227c8@redhat.com>
Subject: Re: [Qemu-devel] [PULL 21/31] block: Avoid bs->blk in bdrv_next()
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org

Am 20.05.2016 um 11:39 hat Paolo Bonzini geschrieben:
> 
> 
> On 20/05/2016 10:10, Kevin Wolf wrote:
> >> > Already posted a fix. I chose to keep the interface and free the
> >> > BdrvNextIterator inside bdrv_next(), when we return NULL after the last
> >> > element.
> > Oops, should have actually read your email... You're right about callers
> > that prematurely exit the loop, of course.
> > 
> > I still don't really like first/next interfaces, though. Perhaps start
> > the iteration with bs == NULL instead of it == NULL?
> 
> Yet another alternative is to add a BDRV_NEXT_ITERATOR_INITIALIZER
> macro.  I like it because it's less magic than "x is NULL" and because I
> would prefer an interface with just the BdrvNextIterator* as the
> argument to bdrv_next.

Hm, we have a few instances where an iterator variable is used for
multiple loops, so we need to be able to use it in an assignment, i.e.
it should be a compound literal. On the other hand, I seem to remember
that compound literals can't be used as initialisers.

Maybe a bdrv_next_iterator_reset() function then? Which would be like
first/next, except that it doesn't return the first value yet.

Kevin