report luns (plus some CAM_DEBUG changes)

[Matthew Jacob]

I believe I addressed Alexander's concerns. I will push this tomorrow 
unless I hear a "Stoi!"

> New patch now in http://people.freebsd.org/~mjacob/active_patches
>
>>>   - removing blank line from xpt_acquire_device() violates style(9).
> fixed
>
>>>   - wouldn't "debug" sounded better the "dflags" in sysctl?
>
> this is matching the previous name usage of cam_dflags.
>
>>>   - is there reason to check CAM_DEV_INQUIRY_DATA_VALID in 
>>> PROBE_REPORT_LUNS?
>
> Just caution. Also, it allows me to avoid sending MODE SENSE to a 
> non-connected lun (case of LUN0 not connected, but we use it to gather 
> REPORT LUNS data)
>
>>>   - 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.
>>>
>>>
>
> I've fixed this by delaying the freeing of the old path in 
> xpt_scan_bus/XPT_SCAN_LUN until *past* the creation of the next path 
> (in the case we have more to scan). This gets us past having the 
> target (with its list of luns) go away out from underneath us in the 
> case that lun0 was scanned but is not itself on the list. I'm much 
> happier with this change.
>
> _______________________________________________
> freebsd-scsi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"