summaryrefslogtreecommitdiff
path: root/sys/dev/microcode/daic
ModeNameSize
-rw-r--r--Makefile1074logplain
-rw-r--r--dnload.h-dist2737logplain
-rw-r--r--gendnloadh2481logplain
in a list on the 'iobuf' list. iobuf_count keeps track of how many buffers are available, and numEmergencyBuffers is the effective "high-water" mark for the freelist. The buffers allocated by rf_AllocIOBuffer() are stripe-unit sized, which is the maximum size requested by any of the callers. Add an iobufs entry to RF_DagHeader_s. Use it for keeping track of buffers that get allocated from the free-list. Add a "generic list" pool (VoidPointerListElement Pool) for elements used to maintain a list of allocated memory. [It is somewhat less than ideal to add another little pool to handle this...] Teach rf_AllocBuffer() to use the new rf_AllocIOBuffer(). Modify other Mallocs to use rf_AllocIOBuffer(), and to update dag_h->iobufs as appropriate. Update rf_FreeDAG() to handle cleanup of dag_h->iobufs. While here, add some missing pool_destroy() calls for a number of pools. With these changes, it should (in theory) be possible to swap on RAID 5 sets again. That said, I've not had any success there yet -- but the last issue I saw at least wasn't in RAIDframe. :-} [There is room for this code to become a bit more consise, but I wanted to do a checkpoint here with something known to work :) ] 2004-03-19Add a few comments to explain what some of these new structures are, andoster where they are used. 2004-03-19Introduce 3 more pools and 6 functions to handle allocating/freeingoster elements from the pools. Re-work rf_SelectAlgorithm() to get rid of all the 8 malloc's, and to use the new functions to get/put these 'support structures'. I'm not overly happy with some of the variable names, but them's the breaks. In the process of changing things, fix a bug: - in the case where we can't create a dag, free asmh_b and blockFuncs too!! [if you were able to look at the source code related to these changes, and comprehend what was going on without having your eyes bleed or getting dizzy, please contact me... I'm sure I'll have more code which would benefit by you having a look at it before I commit it :) ] 2003-12-29[Having received a definite lack of strenuous objection, a small amountoster of strenuous agreement, and some general agreement, this commit is going ahead because it's now starting to block some other changes I wish to make.] Remove most of the support for the concept of "rows" from RAIDframe. While the "row" interface has been exported to the world, RAIDframe internals have really only supported a single row, even though they have feigned support of multiple rows. Nothing changes in configuration land -- config files still need to specify a single row, etc. All auto-config structures remain fully forward/backwards compatible. The only visible difference to the average user should be a reduction in the size of a GENERIC kernel (i386) by 4.5K. For those of us trolling through RAIDframe kernel code, a lot of the driver configuration code has become a LOT easier to read. 2003-02-09constify somejdolecek