* Re: Fibre Channel pass-through for sending arbitrary FC and SCSI commands
2009-10-01 6:35 ` Joe Eykholt
@ 2009-10-01 14:18 ` James Smart
0 siblings, 0 replies; 3+ messages in thread
From: James Smart @ 2009-10-01 14:18 UTC (permalink / raw)
To: Joe Eykholt; +Cc: G S, linux-scsi@vger.kernel.org
Joe Eykholt wrote:
> G S wrote:
>
>> Howdy,
>>
>> The Linux "sg" (SCSI pass-through) can be used to send arbitrary SCSI
>> commands to SCSI target devices.
>>
>> But "sg" doesn't give me access to the transport layer details, such
>> as constructing my own FCP_CMND and receiving FCP_RSP IU's.
>>
>> Is there FC pass-thru in Linux (2.6) SCSI stack, that allows me to
>> construct my own transport frames and payloads?
>>
>
> There's /dev/bsg* that gives lets you send ELS and CT frames, but not
> just any FC frames. You need to configure it under the "Block layer"
> kconfig menu. And perhaps not all HBAs support it. See source
> block/bsg.c for details.
>
>
Although, to date, transport-specific command formats have largely been
confined to the LLDs, I don't know why we couldn't extend the bsg
commands to include something that requests an FCP command execution.
You may still have to wait for individual drivers to support such a
thing (just like the els/ct), but technically, there's no issue.
The downside to this is - any side-band command has the opportunity to
change the scsi state of the device, and do so outside of the knowledge
of the class driver. So any such use is "at your own risk". Consider
scenarios: a) your fcp command clears a CA condition that the class
driver needs to be aware of; or b) app is busy reading tape device,
sideband FCP-based rewind command comes in, repositions tape, app is
unaware of rewind, things get all confused. Even worse if FC-cmd is a
write as tape writes dictate tape records and filemarks, etc.
>> If not, is there vendor (eg. QLogic and Emulex) provided IOCTL module
>> that allows application to interface directly to the HBA driver for
>> doing FC pass-through?
>>
>
> I don't know that.
>
> Joe
>
>
Vendor-provided ioctls are an evil that are not allowed upstream, and
thus typically not allowed in distros either. However, as distro
products must be supportable, when the kernel doesn't have the necessary
infrastructure, the rules get relaxed, although with great debate
first. Vendors can provide out-of-kernel drivers, but this is very
costly for the vendor - there's dislike from the community, there's
lack-of-support from distros, and a yet another driver stream that must
be supported. Thus, the best option if you desire this feature, is to
add the bsg request type indicated above.
-- james s
^ permalink raw reply [flat|nested] 3+ messages in thread