Christoph Hellwig wrote: > On Wed, May 18, 2005 at 04:05:36PM +0200, Hannes Reinecke wrote: >>>If scsi_probe_and_add_lun returns SCSI_SCAN_TARGET_PRESENT sdev isn't valid at >>>this point. You should probably default to SCSI_2 for that case. >>> >>How so? This is exactly the behaviour I've removed. sdev is valid even >>for SCSI_SCAN_TARGET_PRESENT. >>If not please show me. > > Indeed, you replaced the check at the end of scsi_probe_and_add_lun. I don't > think it makes a lot of sense to leave around the stale scsi_dev for PQ3, though. Why not? sg connects to it and you can ask it to provide lots of useless information. Eg doing an report_luns by hand if the configuration of the SAN has changed; PQ3 only states that _this_ device will never have a LUN attached. > > Doing a REPORT_LUNS for SCSI_SCAN_TARGET_PRESENT does OTOH make a lot of sense, > there's nothing in the spec against it. So what about dropping that device > after we're done with REPORT_LUNS? > See above. I'd like to have them around to be able to send commands to it. Cheers, Hannes -- Dr. Hannes Reinecke hare@xxxxxxx SuSE Linux AG S390 & zSeries Maxfeldstraße 5 +49 911 74053 688 90409 Nürnberg http://www.suse.de - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
