Date: Sat, 05 Jun 2010 10:31:49 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Matthew Jacob <mj@feral.com>, freebsd-scsi@freebsd.org Subject: Re: report luns (plus some CAM_DEBUG changes) Message-ID: <4C09FD65.9010406@FreeBSD.org> In-Reply-To: <mailpost.1275699021.5610248.61078.mailing.freebsd.scsi@FreeBSD.cs.nctu.edu.tw> References: <mailpost.1275699021.5610248.61078.mailing.freebsd.scsi@FreeBSD.cs.nctu.edu.tw>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote: > I'm ready to push this I think. Comments before I do? > > See http://people.freebsd.org/~mjacob/active_patches Some comments in order of appearance: - removing blank line from xpt_acquire_device() violates style(9). - wouldn't "debug" sounded better the "dflags" in sysctl? - is there reason to check CAM_DEV_INQUIRY_DATA_VALID in PROBE_REPORT_LUNS? - in PROBE_REPORT_LUNS you are incrementing target->refcount. But who will decrement it back, if XPT_SCAN_LUN was called directly, without XPT_SCAN_BUS/TGT? - while target is probably also counted by scan request and is not going to disappear, do you think direct manipulation with target->refcount (especially decrement) is a good policy? - if xpt_create_path() or something else fails, I think you may leak target->refcount. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C09FD65.9010406>