Subject: Removing "rows" from the RAIDframe driver..
To: None <tech-kern@netbsd.org>
From: Greg Oster <oster@cs.usask.ca>
List: tech-kern
Date: 12/20/2003 10:51:06
Hi

RAIDframe has always had the notion of "rows" and "columns" of
components.  While this interface has been exported to the world, the
RAIDframe internals really only support the concept of "columns", and
while much todo is made about traversing "each row", only a single row
is supported within the kernel.  In particular, upon code inspection,
you will find many of these lines:

 RF_ASSERT(raidPtr->numRow == 1);

sprinkled about, effectively limiting the number of rows to just the
one.


I am therefore proposing to entirely remove from the kernel the
feigned support for multiple rows.  Configuration files, component
labels, etc. will all continue to have the "row" field, but this will
end up getting hard-coded to "1 row" where needed, and "row 0" where a
row value is still required.  Nothing wil change with respect to
configuration of RAID sets.  /usr/include/dev/raidframe/raidframevar.h
will be changed, but those changes will only be related to kernel
internals, and none of the structures used for passing configuration
information will change.

Upside:
 1) Many loops will "shift left" by one tab, allowing for improved
readability of the code.

 2) Many chunks of code will just disappear. (approx 520 lines are
removed, amounting to 24K of code...)

 3) I will have less code to sift through in order to fix the memory
allocation issues.  (The memory allocation bits are really the next
big change that need to be made to RAIDframe.)

 4) Object code will be smaller, and memory footprint of RAIDframe in
a running system will be slightly smaller.  (GENERIC kernel shrinks by
about 4.5K)

 5) Removing "rows" makes doing a number of other improvements
(e.g. moving a "used_spare" into a "spared" component location) a lot
easier.

Downside:
 1) Anyone wishing to make multiple-row support fully functional will
have a LOT of work on their hands to re-add the row bits.

 2) We become "less compatible" with the last distributed version of
RAIDframe.  (That was 5 years ago, and back then there was no plans
for another release.)

I did the work last night in just a few hours (approx 3600 lines of
regular diffs or 8600 lines of context diffs :) ).  If there is
strenuous agreement with this change, I will try to have it tested
well enough to make it into -current this year.  (I'm running the code
right now on my test box, with / on RAID, and playing around, and I
havn't encountered any ill effects yet :) ).

Lacking strenuous agreement, I will wait until mid-January to allow
time for strenuous disagreement and the usual flaming that typically
ensues ;)

Comments, etc. are most welcome.  Context diffs are available upon 
request.

Thanks.

Later...

Greg Oster