lkml.org 
[lkml]   [2005]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
    Luben Tuikov wrote:
    > On 09/30/05 19:57, Jeff Garzik wrote:
    >
    >>Luben Tuikov wrote:
    >>
    >>
    >>>MPT-based drivers + James Bottomley's "transport attributes"
    >>
    >>
    >>You continue to fail to see that a transport class is more than just
    >>transport attributes.
    >>
    >>You continue to fail to see that working on transport class support IS a
    >>transport layer, that includes management.
    >>
    >>Is you don't understand this fundamental stuff, how can we expect you to
    >>get it right?
    >
    >
    >>From what I see, because of its *layering* position
    > JB's "transport attributes" cannot satisfy open transport.
    >
    > The reason is that MPT-based drivers indeed do need host template
    > in the LLDD.
    >
    > Open Transport (SBP/USB/SAS) do not, since the chip is only
    > an interface to the transport.
    >
    > The host template is implemented by a transport layer,
    > say USB Storage or the SAS Transport Layer.
    >

    I think I can understand some of Luben's reasons for the layering. We
    are facing similar problems with software iscsi and hw iscsi. For
    software iscsi it would be nice to consolodate some of the common
    software iscsi code into a layer or lib. Following Luben's path for
    example our queuecommand would be:

    scsi-ml -> scsi_host_template->queuecommand -> iscsi transport common
    queuecommand (do things like check session state, that we are not in
    session level recovery, scsi to iscsi pdu prep like setting the data
    direction, and other iSCSI PDU prep) -> iscsi_transport module ->
    iscsi_transport->queuepdu (you can probably reccomend a better name) ->
    tcp, sctp, iwarp, or some iSCSI HW that exposes a iSCSI interface rather
    than SCSI (note that qla4xxx would use its own
    scsi_host_template->queuecommand since it does not expose enough iSCSI
    internals for it to be useful to plug in here).

    However, HW iscsi cards and software/partial-software iscsi solutions
    can share code for things like session and connection creation where we
    would have transport class lib functions:
    iscsi_add_session/iscsi_remove_session which both the HW iscsi cards
    like qla4xxx and software/partial-software iscsi drivers could use to
    setup things like a common sysfs representation.
    iscsi_add_session/iscsi_remove_session would work similar to the
    fc_rport code where the midlayer doesn't really know they exist (this is
    similar to our session and connection code today but it is bound to the
    scsi host which prevents qla4xxx from using it).

    Is the direction we are going where iscsi would have to put the "iscsi
    transport common queuecommand" code into something similar to libata? Or
    is it that Luben's transport layer code is performing something
    different than software/partial-software iscsi?
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-10-03 21:13    [W:3.974 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site