[illumos-Developer] Webrev: New ARECA arcmsr driver

[Garrett D'Amore]

Thanks for the feedback Rocky.

Eliminating the CLI bypass logic would go a long way to reducing the
complexity of this particular driver.

	- Garrett

On Mon, 2011-03-21 at 16:31 -0700, Rocky Shek wrote:
> Great to see Areca 1880 support in illumos!
> 
> We have used Areca products for a long time.
> 
> The good things about them is they have dedicated management NIC for RAID
> creation and maintenance.
>     
> With that, we did not need more from the Areca CLI or archttp utilities as
> we did in the old day.
> 
> From our point of view, we are fine without cli support  
> 
> Looking forward to the integration 
> 
> Rocky
> -----Original Message-----
> From: Garrett D'Amore [mailto:garrett at nexenta.com] 
> Sent: Friday, March 18, 2011 5:15 PM
> To: developer at lists.illumos.org
> Subject: [illumos-Developer] Webrev: New ARECA arcmsr driver
> 
> Recently, ARECA supplied me with a code drop of their latest Solaris
> code, which supports the Areca 1880 cards, as well as adding support for
> the newer interrupt model and fixing some bugs.
> 
> I want to give a great big *THANK YOU* to Areca for supporting illumos
> in this way!
> 
> That said the code had a number of issues, which I've addressed (if
> anyone wants the original code drop, or the list of issues that I've
> fixed, let me know.)
> 
> The updated driver is posted here in webrev form:
> 
> http://mexico.purplecow.org/gdamore/webrev/arcmsr/
> 
> (Some of the changes are gratuitous reordering... I've not tried to
> remove that reordering... the job was big enough as it was.)
> 
> This code is lint and cstyle clean.
> 
> There are a few more changes I'd like to consider making, but would like
> feedback on, and am thinking would better be done as part of a later
> change set:
> 
> a) removal of the special firmware passthrough support.  It isn't safe,
> and from what I can tell doesn't work.  (Their utility crashes, and I
> cannot get source code for it, limiting my ability to do any debug.)  If
> anyone uses the Areca CLI or archttp utilities with arcmsr, I would
> *really* like to know.  (You can configure and manage the RAID mode
> cards using system BIOS, of course.)
> 
> b) Possibly refactor the code into object oriented bits for each of the
> type A, B, C variants.  (I had done this, but the changes were too
> large, and risky, and so I want to proceed with these lower risk changes
> first.)
> 
> c) Switch to SCSAv3.  This would give some performance boost and remove
> a lot of complexity in the driver.  I've already got a version with
> these changes, but they were again rather large and sweeping, and so
> I've shelved them for a future integration as part of my attempt to
> mitigate risk, and also make the review task a bit more manageable.
> 
> d) remove reset(9e) and replace with quiesce(9e) -- testing needed for
> this.
> 
> e) The code has support for handling 64-bit CDB addressing, but uses DMA
> attributes that prevent it (for good reason!).  We should simply that
> code by removal of the special cases for 64-bit CDB handling.  (Note
> that this does not relate to the *buffer* addresses, which are fully
> 64-bit capable.)
> 
> Anyway, I would really, really like feedback on this driver.  Ideally I
> will be integrating this soon.
> 
> 	- Garrett
> 
> 
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer
>