Quoting "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>:
On Mon, 2016-04-04 at 13:59 -0400, Bryant G Ly wrote:
Hi Nick,
Quoting "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>:
> On Wed, 2016-03-16 at 14:29 -0400, Bryant G Ly wrote:
>> Quoting "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>:
<SNIP>
>> Also, do you know if host aka ibmvscsi is supposed to add something
>> into our queue
>> asking for what we have attached aka luns in this scenario? I would think
>> after login, they should add a queue to ask the target what we have?
>>
>
> Mmmm, AFAIK this is done using the REPORT_LUNS payload with the special
> make_lun() encoding in ibmvscsis_report_luns().
>
You had mentioned to use spc_emulate_report_luns(). By this do you
mean checking the cdb for REPORT_LUNS, then if so modify the
deve->mapped_lun so that it
is in the make_lun() encoding and then calling spc_emulate_report_luns()?
deve->mapped_lun should not be modified directly. ;)
I was thinking to add an optional target_core_fabric_ops->encode_lun()
function pointer, that allows drivers to provide a fabric dependent
method invoked by spc_emulate_report_luns() to handle the special case.
In the case of ibmvscsis, the existing make_lun() code would be invoked
by the new ->encode_lun() caller from generic code.
Beyond that, I'm not sure if ibmvscsis_report_luns() has any other
limitations wrt to buffer size, maxinum number of luns, etc, that
spc_emulate_report_luns() would also need to honor.
Afterwards probably call ibmvscsis_queue_data_in() ?
Correct, target_core_fabric_ops->queue_data_in() is already invoked to
queue the response after spc_emulate_report_luns() has populated the
payload.
I had learned from the VIOS folks that report luns doesn't need any special
encoding, so we should be able to just use spc_emulate_report_luns() directly.
Therefore, I wont be making any changes to do encoding stuff, unless
you think it'll
be useful for other drivers? I think mode_sense can also be scrapped
and just use the common spc_emulate code. For inquiry we can either use the
existing or try to make spc_emulate_inquiry account for this emulation.
But on a side note, I think I have a SCSI scan that starts after the
login request
is complete, which is good I think that is the report_luns request that I'm
seeking. Do you know how to make the target init go first? As in having
transport_init_session, core_tpg_check_initiator_node_acl, and
transport_register_session all occur prior to ibmvscsis_probe being
called? This way
I can ensure target has mapped backstores/luns prior to this driver
starting. I think
this will fix the whole issue with client adapter not seeing the luns.
Offtopic: I am going to be in North Carolina for the VAULT conference
on the 18th and flying out the 21st after the last session. Let me
know of a good time
we can meet with a colleague of mine who is the VIOS architect. We
are in the
works of open sourcing the current existing VIOS driver that is IBM
proprietary, and
plan on using it to further develop this driver/add to LIO. For
example we would like to add
virtual disks into LIO as a backstore (which currently already exists in our
own properitary code).
Neat. 8-)
It's also the reason for the slower development
and progress of this driver since there is still an internal debate in
regards to whether or not we want to work off the internal driver
or add to this
one that you have seen.
I'll be around the entire week, so let me know a time off-list that
works for you and the VIOS folks, and will plan accordingly.
I'll be free anytime on the 19th, but Bob, the VIOS architect wont be there
until the 20th. We can either meet first and talk about technical stuff in
relations to LIO. Or on the 20th we can meet and talk about our level of
commitment and mission towards Vscsi/LIO enhancements along with technical
questions in relation to LIO. On the 20th, Bob and I can accommodate any time
that you are free.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
