Hi guys, :-)
That's a lot of email. :-)
On 08/15/05 11:23, James Bottomley wrote:
> On Mon, 2005-08-15 at 11:18 -0400, Luben Tuikov wrote:
>
>>While you're at it, rip out the extremely broken "channel" and "id",
>>and leave only the opaque token.
>
>
> Unfortunately, I just found an actual use for channel (exposing
> underlying physical discs of raid devices) and, unfortunately, we're
> still not yet at the point where we can use an opaque token for ID, but
> if someone wants to look into what it would take to convert the rest of
> SCSI ...
Hmm, you've
"found an actual use for channel (exposing underlying physical discs
of raid devices)".
I'm completely befuddled James.
What if we didn't have "channel" (SPI leftover) in the first place?
Or, if an LU is implemented as a RAID device, how do you find out its
individual disks?
Is there a spec or standard that you're following in doing this?
On 08/15/05 11:25, Christoph Hellwig wrote:
> On Mon, Aug 15, 2005 at 11:18:10AM -0400, Luben Tuikov wrote:
>
>>On 08/15/05 09:42, Christoph Hellwig wrote:
>>
>>>Add a new void *transport_data argument to scsi_scan_target so that a
>>>transport-class can fill in known information before actually scanning
>>>the target. This is needed by the upcoming SAS transport class patch.
>>
>>Hmm, yes, this has been due for 5 years now.
>>
>>While you're at it, rip out the extremely broken "channel" and "id",
>>and leave only the opaque token.
>
> Well, it's not a token but pre-initialized data. The problem with
> ripping out channel and id is that userland would break all over,
> else we'd have done it already.
Ah, ok.
Is it possible to figure out which parts of userland rely on
HCIL tuples, as opposed to "scsi device I can send commands to"?
Than we can fix those userland programs and we can move into
the future.
Luben
-
: 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
