Garrett D'Amore writes:
> There is a closed version, which includes one closed file fix, at
> 
> http://jurassic.sfbay/~gd78059/webrev/mblkl

Thanks for doing this!

uts/common/fs/smbclnt/netsmb/smb_trantcp.c

  I don't think I'd add a copyright message here, but check with the
  gatekeepers.  The usual rule is that if it's just changes in
  commentary or "trivial" matters like lint warnings, then you don't
  add or change the copyright notice.

uts/common/inet/vni/vni.c
uts/common/io/aggr/aggr_ctl.c
uts/common/io/ath/ath_aux.c

  I don't see where these (and several others I didn't list) have any
  MBLKL changes in them, or where the bug you're citing includes these
  changes.  I agree that the clean-up is nice, though.  Perhaps you'll
  want to add a note to your Evaluation.

uts/common/io/dmfe/dmfe_mii.c

  258: this seems a little random.

uts/common/io/ib/mgt/ibcm/ibcm_arp_link.c

  573: why is the /* LINTED */ no longer needed?  I don't see a void *
       cast on this one.

uts/common/io/rge/rge_chip.c

  299: what's this?

uts/common/io/usb/hcd/uhci/uhcipolled.c

  258: not sure what changed here.  (?)

uts/common/io/vuidmice/vuidmice.c

  676: this has an extra (caddr_t) cast that can be dropped.  (The
       result of dereferencing (caddr_t *) is just caddr_t.)

  724: this shouldn't have passed cstyle; missing space between "void"
       and "*".

uts/common/io/vuidmice/vuidps2.c

  519: I think the better way to write this is mp->b_wptr >
       mp->b_rptr.  Comparing MBLKL against zero seems odd to me.

uts/common/io/wscons.c

  710: random?

uts/common/ktli/t_kconnect.c

  196: is the cast still needed?

uts/common/ktli/t_krcvudat.c

  220: cast needed?

uts/intel/amd8111s/Makefile

  56-59: I'd remove the empty section as well.

uts/intel/pcwl/Makefile

  75: remove

uts/intel/wpi/Makefile

  61: why do *some* of the Makefiles still have E_BAD_PTR_CAST_ALIGN?
      It looks like you went to some trouble to rip these out.  Are
      some lint nits still left, or are the Makefiles incorrectly
      suppressing these warnings?

-- 
James Carlson, Solaris Networking              <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to