The function to specify the read buffers is called
scsi_task_add_data_in_buffer, not scsi_task_add_data_buffer
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
It is not real zero-copy since the data is still copied in the kernel,
but it avoids copying the data inside libiscsi as well as in the callback.
For SCSI tasks that will return data from the target, the application can now
specify application buffers for libiscsi to read the data directly into.
This is done by calling scsi_task_add_data_in_buffer(task, ...
These buffers need not be linear, you can specify different areas to read into
by calling this function several times.
See examples/iscsiclient.c for an example.
Add a mechanism where residual overflow/underflow can be reportad back to
the application
We probably need somethinf for bidir residuals at some stage too
We dotn need two interfaces that only diuffer in whether they return a pointer or NULL vs an semiidentical interface that returns 0 or <0
All uses of _async() for scsi tasks should be replaced with the equivalent _task() function instead
These functions are also async functions for SCSI commands but they return
a task structure or NULL.
This task structure can be used in task management functions to abort the task or a whole task set.
are in flight at the moment.
Aside from commands, we also consider the "has not yet connected completely" as being an i/o.
When this command returns 0 it means we are connected ant the iscsi connection is idle, with no commands in flight.
KVM needs a function to detect idleness like this for its block layer io_flush
function.
LBA is uint32_t for read/write10
Also store the lba/numblocks arguments in the task structure for read10/write10
This makes it much easier to implement a fully async "read lots/write lots"
applications.
A Portal URL is of the form
iscsi://[<username>[%<password>]@]<host>[:<port>]
and is used by command such as iscsi-ls during the discovery login phase.
During discovery we do not yet know the target iqn name, nor the lun of
any devices.
Update the "send scsi command" fucntion to honour
"FirstBurstLength" so that we only send this many bytes as unsolicited data.
The wait for a train of R2T from the target to clock out additional
busrts of data until the full task data has been sent to the Target.
We should now honour, and handle the case of
ImmediateData=No
InitialR2T=No
correctly for targets that are limited on receiveing data too fast.
Update the send pdu command to trap when we need to send data to the target
but we are not allowed to send using immediate data.
For this case, send the data as a separate DATAOUT pdu instead.
Twiddle the flags and other fields to now manage that we send the data
as two separate PDUs.
This function can allocate a new pdu using a specific itt value
and specific flags instead of using the defaults of, next iff, no flags set.
This can be used when we need to allocate additional PDUs in a chain,
for commands that span across multiple PDUs and where all need to keep
the same itt value.
For example
->WRITE10 cdb
->DATAOUT
-<RESPONSE
Here the DATAOUT PDU belongs to the same task that was started by write10
so it need to use the same itt value.
This flag is used when we dont want the CANCEL callback to be invoked if the
context is destroyed.
Thsi will be used for the sequence where we send multiple PDUs
to the target for one single scsi task, such as
-> WRITE10 cdb
-> DATAOUT
-< RESPONSE
Since if the context is destroyed when the command is in flight, we
already get the CANCEL callback for the WRITE10 PDU, so we dont need to invoke
it again for when we destroy the DATAOUT pdu, since they both refer to the same
task.
Add a new pdu flag : DELETE_WHEN_SENT. When this pdu has been
sent to the wire, the pdu will be deleted and not put on the waitpdu list.
This will be useful for sequences such as
-> WRITE10 cdb
-> DATAOUT the data to write
-< RESPONSE
Where we want to match WRITE10 and RESPONSE but where the plain DATAOUT pdu
will not be soliciting its own response.
We dont need to wait for the response to DATAOUT pdus, we are already waitin
for the response form the initial PDU in the sequence.
We will use this later to decide when we should send unsolicited imemdiate
data to the target. Currently we always send unsolicited immediate data
but targets configured to not allow immediate data may refuce this and
turn an error.
and accept what Target responds.
Store the result of the negotiated setting in the iscsi context
so we can use it later to determine how to send solicited/unsolicited
data.
Add these settings to the iscsi context structure and initialize them to
sane valued.
When sending login commands to the target, use these values instead
of hardcoded values.
Parse when the target sends a login reply back to us and update these variables
if the target asks us to.
This allows us to detect when our defaults are too big for the target
and adjust the settings we use so we match the target.
Some targets have a very small accepted default for some settings.
During login, we will initially send these keys with our dafult values.
These targets will then respond back by refusing to transition to the next
login phase, and by telling us back what the maximum of these values should be.
In this case we have to try the login again but use the smaller values we got
from the target.
Othervise, if we try again, ignoring the value from the target, and just repeat
using our defaults the target will abort the login with a "initiator error".
Add unidirectional chap support so we can authenticate to the target.
Make the login phase more "intelligent" so we can iterate over login
pdus until we have reached full feature phase
Add a new helper functions to parse a iscsi url and break it down
into elements in a structure
Update iscsi-inq to allow CHAP authentication
