[illumos-Developer] Webrev: New ARECA arcmsr driver
Dan McDonald
danmcd at nexenta.com
Wed Mar 23 22:20:34 PDT 2011
On Fri, Mar 18, 2011 at 7:15 PM, Garrett D'Amore <garrett at nexenta.com> wrote:
> 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/
A LOT of what I have to say will probably be applicable to your second whack
on this code. Hopefully the contributors will take my advice to heart as
well.
usr/src/uts/intel/io/scsi/adapters/arcmsr/arcmsr.h
* PtrToNum() & friends:
- Use "void *" instead of caddr_t * unless there's a really
good reason.
- I believe "uintptr_t" is the type you use for pointers-as-numbers.
This rids you of your _LP64 ifdef crap as it does the right thing
regardless.
* Lines 537-543: redundant?
* struct ACB: It'd be nice to know what the new mutexes are protecting.
usr/src/uts/intel/io/scsi/adapters/arcmsr/arcmsr.c
* Line 150... should that have an "ll" or "ull" at the end of the constant?
* ObPetPeeve: I hate "if (!ptr)", and prefer "if (ptr == NULL)". The
compiler spits out the same code for either.
* Line 480 - Dumb question, and maybe I'll answer this myself, but how can we
make the datamodel-matching guarantee here?
* Lines 517,541, etc. - WTF call memcpy() for one byte?! (If the theoretical
"functional strength reduction" I wrote about for advanced graduate
compilers is available, sure this'll fall out, but ewwww....)
* Line 731 - It *appears* that in this case, you leak "pktioctlfld".
* Line 1137 --> See Albert's previous comment. ;)
* General --> I see mixed uses of memcpy() and bcopy(). IIRC, kernel bcopy()
is much faster than kernel memcpy(). This doesn't count the length == 1
instances, which are just dumb.
* Lines 1407, 1412-1413 --> redundant, nuke 'em.
* Line 1425... do you want to clear ACB_F_BUS_RESET even if you return
failure?
* Lines 1995-2001: This sort of behavior always makes me nervous.
* Line 2254: C++ comment allowed?
* Line 2282: (void) strlcpy(devbuf, devnm, sizeof (devbuf));
(Unless you have IRON CLAD guarantees about the input.)
* Line 2283: WTF? Assigning a character-constant to a *pointer*?!
I'd look at this function a bit harder.
* Line 3756, others: ewww, hardcoded 20 seconds. #define please?
* Line 3764, same here.
* Rest seems okay, but I'm not a low-level driver wizard.
Hope this helps,
Dan
More information about the Developer
mailing list