----- Original Message -----
From: "Prasenjit Sarkar" <[EMAIL PROTECTED]>
To: "Eric Youngdale" <[EMAIL PROTECTED]>
Cc: "Torben Mathiasen" <[EMAIL PROTECTED]>; "Douglas Gilbert"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, January 08, 2001 5:17 PM
Subject: Re: [PATCH, RFC] SCSI cleanups for 2.5
>
>
> Hi Eric,
>
> WRT #4 there is an ongoing SCSI over IP going on in industry in various
> forms (iSCSI, FCIP and iFCP)
> - using Linux as a platform for an ISCSI appliance (akin to NFS and Samba)
> might be attractive.
> With that in mind, would it be possible to still expose scsi_do_cmd()
> outside of the SCSI core so that
> the iSCSI servers can access the SCSI functions in the same way sd/st/sg
> do....
Yes, in the 2.4 kernel we ended up adding a distinction between a
"request" and a "command", and this was an outgrowth of the new queueing
code. The idea is that a "command" is a concept that is only relevant to
the mid-layer and the associated low-level driver. It represents a command
that is either currently queued, or in the process of becoming queued.
A request is essentially the type of entity that sg/st use. The idea is
that when a user request for data comes in, this gets converted into a
ScsiRequest and inserted into the request queue. When this request reaches
the top of the queue, then it gets converted to a Scsi_Command and queued to
the actual device.
Anyways, the upshot is that anyone else wishing to inject commands into
a device queue should not use scsi_do_cmd() and instead use scsi_do_req()
(the Scsi_Request based interface).
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
