On 12/01/2009 02:00 PM, Tejun Heo wrote:I thought about that but didn't want to open code the special and
fairly complex loop construct used there. To me, it seemed using the
same loop construct would be much less error-prone than open coding
the loop mostly because those two special cases are the only place
where that is necessary. Maybe we can add pcpu_first_[un]pop_region()
macros and use them there but is the first iteration check that bad
even with sufficient explanations?
So, something like the following.
#define pcpu_first_unpop_region(chunk, rs, re, start, end) do { \
(rs) = (start); \
pcpu_next_unpop((chunk), &(rs), &(re), (end)); \
} while (0)
#define pcpu_for_each_unpop_region(chunk, rs, re, start, end) \
for (pcpu_first_unpop_region(chunk, rs, re, start, end); \
(rs) < (re); \
(rs) = (re) + 1, pcpu_next_unpop((chunk), &(rs), &(re), (end)))
#define pcpu_first_pop_region(chunk, rs, re, start, end) do { \
(rs) = (start); \
pcpu_next_pop((chunk), &(rs), &(re), (end)); \
} while (0)
#define pcpu_for_each_pop_region(chunk, rs, re, start, end) \
for (pcpu_first_pop_region(chunk, rs, re, start, end); \
(rs) < (re); \
(rs) = (re) + 1, pcpu_next_pop((chunk), &(rs), &(re), (end)))
It might be better to make these proper functions which take pointers
but that makes the only two interfaces for region iterators disagree
about how they take parameters.
So, I don't know. The first iteration only loop looks a bit unusual
for sure but it isn't something conceptually convoluted.