Hey Dale, They could if someone didn't read any of the documentation for example. In general, the name of the provider pertaining to the server (or target) gets the protocol name and the client (or initiator) has an additional suffix.
Adam On Tue, Jun 30, 2009 at 07:34:18PM -0400, Dale Ghent wrote: > > Cool plan, but could any of these COMSTAR FCTP-specific probes be > misconstrued as having something to do with leadvile/fibre channel > initiators? > > /dale > > On Jun 30, 2009, at 12:33 PM, Adam Leventhal wrote: > >> For the PSARC record, Allan Ou has made the following additions under the >> aegis of the original close approved automatic case: >> >> 4.1 Probes overview >> >> Fibre Channel Event Type Probes >> ------------------------ ------ >> rscn receive fc:::rscn-receive >> abts receive fc:::abts-receive >> >> 4.3 Detailed probes specification >> >> 4.3.6 RSCN Packet Probes >> >> fc:::rscn-receive trace all RSCN packets target port received >> >> Probes Variable Type Description >> ----- --------- ---- ----------- >> fc:::rscn-receive args[0] conninfo_t * connection info >> fc:::rscn-receive args[1] fc_port_info_t * local port info >> fc:::rscn-receive args[2] int port id >> >> args[2] is the port id which retrived from RSCN pages >> >> 4.3.7 ABTS Packet Probes >> >> Probes Variable Type Description >> ------ -------- ---- ----------- >> fc:::abts-receive args[0] conninfo_t * connection info >> fc:::abts-receive args[1] fc_port_info_t * local port info >> fc:::abts-receive args[2] fc_port_info_t * remote port info >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc at opensolaris.org > -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
