01 Mar, 2011

1 commit


28 Jul, 2010

1 commit

  • Add functions to fill in an FC header given a request header.
    These reduces code lines in fc_lport and fc_rport and works
    without an exchange/sequence assigned.

    fc_fill_reply_hdr() fills a header for a final reply frame.

    fc_fill_hdr() which is similar but allows specifying the
    f_ctl parameter.

    Add defines for F_CTL values FC_FCTL_REQ and FC_FCTL_RESP.
    These can be used for most request and response sequences.

    v2 of patch adds a line to copy the frame encapsulation
    info from the received frame.

    Signed-off-by: Joe Eykholt
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Joe Eykholt
     

17 May, 2010

1 commit

  • This patch creates a port_id member in struct fc_lport.
    This allows libfc to just deal with fc_lport instances
    instead of calling into the fc_host to get the port_id.

    This change helps in only using symbols necessary for
    operation from the libfc structures. libfc still needs
    to change the fc_host_port_id() if the port_id changes
    so the presentation layer (scsi_transport_fc) can provide
    the user with the correct value, but libfc shouldn't
    rely on the presentation layer for operational values.

    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Robert Love
     

05 Dec, 2009

7 commits

  • Customers and certification tests have pointed out that we don't
    show up on the switch management software as an initiator.

    On some MDS switches 'show fcns database' command shows libfc
    initiators as 'fcp' not 'fcp:init' like other initiators.

    On others switches, I think the switch gets the features by doing a PRLI,
    but it may be only certain models or under certain configurations.

    Fix this by registering our FC4 features with the RFF_ID CT request
    after local port login and after the RFT_ID.

    Signed-off-by: Joe Eykholt
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Joe Eykholt
     
  • The strncpy for RSPN_ID and RSNN_NN requests was padding
    past the allocated frame size.

    Get the string length before filling in the ct header.

    Signed-off-by: Joe Eykholt
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Joe Eykholt
     
  • The code that filled in the name server RNN_ID (register node name)
    request had somehow gotten a line in it from the RFT_ID code
    which copies 32 bytes of data over the relatively short payload.
    This caused some corruption and hangs.

    Simply deleted the extraneous line.

    Signed-off-by: Joe Eykholt
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Joe Eykholt
     
  • Register the fc_host symbolic name as the symbolic port name
    with the fabric name server.

    Signed-off-by: Chris Leech
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Chris Leech
     
  • Register the fc_host symbolic name as the symbolic node name
    with the fabric name server.

    Signed-off-by: Chris Leech
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Chris Leech
     
  • One could interpret FC-GS-5 to say that an explicit RNN_ID is required
    before RSNN_NN is allowed to succeed, which is why RNN_ID was not obsoleted
    along with RPN_ID acording to this document:
    ftp://ftp.t11.org/t11/member/fc/gs-5/05-546v2.pdf

    Signed-off-by: Chris Leech
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Chris Leech
     
  • Add FDISC ELS handling to libfc and libfcoe, treat it the same as FLOGI where
    appropriate.

    Add checking for NPIV support in the FLOGI LS_ACC service parameters.

    Signed-off-by: Chris Leech
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Chris Leech
     

11 Sep, 2009

4 commits

  • When an RSCN indicates changes to individual remote ports,
    don't blindly log them out and then back in. Instead, determine
    whether they're still in the directory, by doing GPN_ID.

    If that is successful, call login, which will send ADISC and reverify,
    otherwise, call logoff. Perhaps we should just delete the rport,
    not send LOGO, but it seems safer.

    Also, fix a possible issue where if a mix of records in the RSCN
    cause us to queue disc_ports for disc_single and then we decide
    to do full rediscovery, we leak memory for those disc_ports queued.

    So, go through the list of disc_ports even if doing full discovery.
    Free the disc_ports in any case. If any of the disc_single() calls
    return error, do a full discovery.

    The ability to fill in GPN_ID requests was added to fc_ct_fill().
    For this, it needs the FC_ID to be passed in as an arg.
    The did parameter for fc_elsct_send() is used for that, since the
    actual D_DID will always be 0xfffffc for all CT requests so far.

    Signed-off-by: Joe Eykholt
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Joe Eykholt
     
  • When rport_login is called on an rport that is already thought
    to be logged in, use ADISC. If that fails, redo PLOGI.
    This is less disruptive after fabric changes that don't affect
    the state of the target.

    Implement the sending of ADISC via fc_els_fill.

    Add ADISC state to the rport state machine. This is entered from READY
    and returns to READY after successful completion. If it fails, the rport
    is either logged off and deleted or re-does PLOGI.

    Signed-off-by: Joe Eykholt
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Joe Eykholt
     
  • tt.elsct_send is used by both FCP and by the rport state machine.
    After further patches, these two modules will use different
    structures for the remote port.

    So, change elsct_send to use the FC_ID instead of the fc_rport_priv
    as its argument. It currently only uses the FC_ID anyway.

    For CT requests the destination FC_ID is still implicitly 0xfffffc.
    After further patches the did arg on CT requests will be used to
    specify the FC_ID being inquired about for GPN_ID or other queries.

    Signed-off-by: Joe Eykholt
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Joe Eykholt
     
  • The rport and discovery modules deal with remote ports
    before fc_remote_port_add() can be done, because the
    full set of rport identifiers is not known at early stages.

    In preparation for splitting the fc_rport/fc_rport_priv allocation,
    make fc_rport_priv the primary interface for the remote port and
    discovery engines.

    The FCP / SCSI layers still deal with fc_rport and
    fc_rport_libfc_priv, however.

    Signed-off-by: Joe Eykholt
    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Joe Eykholt
     

22 Jun, 2009

1 commit

  • This patch adds the /sys/module/libfc/parameters/debug_logging
    file to sysfs as a module parameter. It accepts an integer
    bitmask for logging. Currently it supports:

    bit
    LSB 0 = general libfc debugging
    1 = lport debugging
    2 = disc debugging
    3 = rport debugging
    4 = fcp debugging
    5 = EM debugging
    6 = exch/seq debugging
    7 = scsi logging (mostly error handling)

    the other bits are not used at this time.

    The patch converts all of the libfc source files to use
    these new macros and removes the old FC_DBG macro.

    Signed-off-by: Robert Love
    Signed-off-by: James Bottomley

    Robert Love
     

30 Dec, 2008

1 commit

  • libFC is composed of 4 blocks supported by an exchange manager
    and a framing library. The upper 4 layers are fc_lport, fc_disc,
    fc_rport and fc_fcp. A LLD that uses libfc could choose to
    either use libfc's block, or using the transport template
    defined in libfc.h, override one or more blocks with its own
    implementation.

    The EM (Exchange Manager) manages exhcanges/sequences for all
    commands- ELS, CT and FCP.

    The framing library frames ELS and CT commands.

    The fc_lport block manages the library's representation of the
    host's FC enabled ports.

    The fc_disc block manages discovery of targets as well as
    handling changes that occur in the FC fabric (via. RSCN events).

    The fc_rport block manages the library's representation of other
    entities in the FC fabric. Currently the library uses this block
    for targets, its peer when in point-to-point mode and the
    directory server, but can be extended for other entities if
    needed.

    The fc_fcp block interacts with the scsi-ml and handles all
    I/O.

    Signed-off-by: Robert Love
    [jejb: added include of delay.h to fix ppc64 compile prob spotted by sfr]
    Signed-off-by: James Bottomley

    Robert Love