Messages in this thread | | | Date | Tue, 13 Sep 2005 15:42:15 -0700 | From | Patrick Mansfield <> | Subject | Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices) |
| |
On Tue, Sep 13, 2005 at 07:05:15PM +1000, Douglas Gilbert wrote: > 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.
It should ignore the lun value for REPORT LUNS.
> 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.
What I mean is that the target has to intercept the command whether it is a REPORT LUN or for the well known (W_LUN).
The target (firmware) code has to have code today like:
if (cmd == REPORT_LUN) { do_report_lun(); }
For only W_LUN support, the code might be something like:
if (lun == W_LUN) { if (cmd == REPORT_LUN) { do_report_lun(); } }
But the first case above already covers even the W_LUN case.
So adding a W_LUN at this point does not add any value ... maybe it looks nice in the spec and in someones firmware, but it does not add anything that I can see.
Kind of like an 8 byte lun, it adds no meaningful functionallity. [I mean, who would want 2^64 LUs on one target? Yeh, let's give everyone in the world ... no in the universe their own private LUN on a single target. The LUN hiearchy is a bad idea, I have not seen a device that supports it, kind of like trying to implement network routing inside your storage box. Don't let those storage or database experts design your network hardware.]
-- Patrick Mansfield - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |