[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190702115225.GB3419@hirez.programming.kicks-ass.net>
Date: Tue, 2 Jul 2019 13:52:25 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Michel Lespinasse <walken@...gle.com>
Cc: Davidlohr Bueso <dave@...olabs.net>,
David Howells <dhowells@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/3] augmented rbtree: rework the RB_DECLARE_CALLBACKS
macro definition
On Tue, Jul 02, 2019 at 12:58:19AM -0700, Michel Lespinasse wrote:
> - Change the definition of the RBCOMPUTE function. The propagate
> callback repeatedly calls RBCOMPUTE as it moves from leaf to root.
> it wants to stop recomputing once the augmented subtree information
> doesn't change. This was previously checked using the == operator,
> but that only works when the augmented subtree information is a
> scalar field. This commit modifies the RBCOMPUTE function so that
> it now sets the augmented subtree information instead of returning it,
> and returns a boolean value indicating if the propagate callback
> should stop.
I suppose that makes sense and saves a copy over adding RBEQUAL() like I
proposed earlier.
> - Reorder the RB_DECLARE_CALLBACKS macro arguments, following the
> style of the INTERVAL_TREE_DEFINE macro, so that RBSTATIC and RBNAME
> are passed last.
That's, IMO, a weird change. C has storage type and name first, why
would you want to put that last. If anything, change
INTERVAL_TREE_DEFINE().
Also; this is two changes and one patch; ISTR we have rules about those
things :-)
> The motivation for this change is that I want to introduce augmented rbtree
> uses where the augmented data for the subtree is a struct instead of a scalar.
I'm not seeing how this justifies the second thing.
Powered by blists - more mailing lists