Re: [PATCH 05/10] Introduce ridr_get_new_above()

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Tim Pepper
Date: Wednesday, April 30, 2008 - 9:32 pm

On Tue 29 Apr at 16:33:09 +0200 Nadia.Derbey@bull.net said:

The ridr_get_new_above() is the first place we see something really
different compared to idr (an RCU addition).  This is a lot of patching
so far for what would be a small incremental change otherwise.


This stuff is useful on its own in as much as it improves code
readability.  A lot of this patch (the "some common code between the
idr and ridr API's" part) could be a standalone patch distinct from the
ridr series and then be at the head of your stack.


Why the added BUG_ON()?  These couple hunks are a bit muddled, so maybe I
missed something.  But I don't see anything different in how m or bm are
being manipulated such that m<0 is anymore likely after this patch.


idr's alloc_layer() in disguise?


...
More or less duplication
...


Oh but wait..there's some RCU-ness tucked in there.

               ^^                   ^^
Dropped some parens.  Otherwise more duplication...


Some more RCU.


And other line of RCU.

OK.  So at this point in patch 5/10 we've got 3 lines of new code and
hundreds of lines of duplicated code?

A while more looking through the rest of the patches for the rest of the
context and I might be able to actually think about the implications of
these three lines being where they are.

Locking changes are complicated enough without all this obfuscation!
I understand the desire to not break IDR, but...

-- 
Tim Pepper  <lnxninja@linux.vnet.ibm.com>
IBM Linux Technology Center
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 05/10] Introduce ridr_get_new_above(), Nadia.Derbey, (Tue Apr 29, 7:33 am)
Re: [PATCH 05/10] Introduce ridr_get_new_above(), Tim Pepper, (Wed Apr 30, 9:32 pm)
Re: [PATCH 05/10] Introduce ridr_get_new_above(), Nadia Derbey, (Mon May 5, 3:33 am)