Patrick Mansfield wrote: > On Mon, Sep 12, 2005 at 11:06:37AM -0400, Luben Tuikov wrote: <snip> > IMO adding well known LUNs at this point to the standard added nothing of > value, the target firmware has to check for special paths no matter what, > adding a well known LUN does not change that. And most vendors will > (likely) have support for use without a well known LUN. (This does not > mean we should not support it in linux, I just don't know why this went > into the standard.) > > Using well known LUNs will be another code path that will have to live > alongside existing ones, and will likely require further black listing > (similar to REPORT LUN vs scanning for LUNs). Patrick, The technique of supporting REPORT_LUNS on lun 0 of a target in the case where there is no such device (logical unit) is a pretty ugly. It also indicates what is really happening: the target device intercepts REPORT_LUNS, builds the response and replies on behalf of lun 0. Turns out there are other reasons an application may want to "talk" to a target device rather than one of its logical units (e.g. access controls and log pages specific to the target's transport). Well known lus can be seen with the REPORT_LUNS (select_report=1) but there is no mechanism (that I am aware of) that allows anyone to access them from the user space with linux. References at www.t10.org: spc4r01a.pdf [section 8] bcc-r00.pdf [bridge controller commands] Doug Gilbert - : 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
