Nope - not forgotten, just a lot of different things to get to.
I don't know of anything in the header that needs to be specified.
Everything is either fixed because it is an ELS/CT request, or what
needs to be specified (usually S_ID/D_ID) comes from the object the bsg
reference is to. CS_CTL is the only one that is a maybe - but that's a
whole different story, and we should just ignore it for now. So I'm
against a header.
Additionally, we have to be careful about what kind of interface we
believe the LLD's support. If they expected a raw frame transmit, I
don't know how many support that, especially as adapters very much
control XID's, etc. Create Exchange, w/ Send/Receive, sequence is
prefered, but even that might be too low. At best, there is explicit
els or ct assist interfaces - which means the LLD/adapter is likely
handling all the header and segmentation, and the interface is just
passing payload buffers.
So in general it's a request, w/ xmt payload, buffer for response, and a
completion status (which I would assume is more than just an int and a
couple of #defines - we have to cover the F_RJT/P_RJT/ABORT cases..)
-- james s
Seokmann Ju wrote:
I just want to re-stroke this thread to make sure it is not skipped.
One question came to me while testing qla2xxx module with the changes.
When the application issues ELS/CT packet, should the packet include
the FC frame header?
And if the answer is 'yes', should the driver also include the FC
frame header when it returns response to the application (just like
any other frame exchanges in between two ports on the FC)?
The FC frame header has type field that identifies what type of the
payload (ELS / CT / etc.) the frame contains and the type field is
being checked by the FC transport layer before it calls LLDD's handler.
Thank you,
Seokmann
--
To unsubscribe from this list: 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