Hi liujun > The link,http://www.opensolaris.org/os/community/arc/caselog/1999/647/, > gives our overview about the MPxIO.It's so cool. > > When want to learn more , I find that i am dropped into a loop . The > problem is what the relative between tvhci, tphci, tcli . I can't find > some right flows such as detect a device and register it into MPxIO. > From some material linked > http://www.opensolaris.org/os/project/mpxio/, I can sure scsi_vhci is > load before tvhci, tphci, tcli . Have some puzzles about the inital > flow. The mdi_pi_alloc is the entry point of alloc path info. But in > that functions ,it need some vchi infomations,when the vchi is alloc? > I'm sorry for describing problem so disorder. But I hope your Tips > ,Thanks
The tvhci-tphci-tcli drivers are one example of a vhci-phci-client set of drivers that use the mdi(MPXIO) framework. People tend to think of MPXIO has a SCSI-thing, but other the mdi(MPXIO) framework can be used for other things too (like infiniband). For scsi o the tvhci peer is the scsi_vhci (a virtual SCSA HBA driver) http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/scsi/adapters/scsi_vhci / o some scsi tphci peers that are open sourced (in nws consolidation) are o leadville fibre-channel scsi initiator: http://src.opensolaris.org/source/xref/nwsc/src/sun_nws/fcp/ o iscsi initiator: http://src.opensolaris.org/source/xref/nwsc/src/sun_nws/iscsi/ o there is other SCSA pHCI initiator code that is not open (like mpt and ibsrp). o some scsi tclient peers are sd, st, etc http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/scsi/targets/ In regard to how this works for scsi, reading scsi(4) might help a little. At the SCSI HBA driver level, we need more work in the SCSA framework to transparently support self-identifying devices (without bringing in a bunch of non-ddi ndi_* and mdi_* interfaces knowledge and complex locking into the HBA drivers)- so a SCSA phci HBA driver can remain just an HBA driver (with minor enhancements). A lot of the ARC materials covering auto configuration (devfs, bus_config, and bus_config into SCSA HBA drivers (all new in S10)) are still private, largely because noone has had the time to sanitize them. For SCSI HBA drivers, what they describe (as can be seen in the phci code above) still places too much implementation burden on the driver writer - so making the material public would help in understanding, but would not help lift the inappropriately large burden currently placed on pHCI driver writers. NOTE: leadville fcp code bears this burden for all hardware that operate under leadville (qlc, emlx). In general, device auto configuration is on-demand driven for the /devices file system (devfs), into framework auto configuration code (devcfg.c), and out into the nexus drivers (or a default implementation back in the devcfg.c code). This applies to the scsi_vhci driver too - the scsi_vhci code maintains a cache of which phci /devices paths last supported access to a given devid/LUN-GUID, and drives configuration down those specific pHCI paths. There are a lot of moving parts. -Chris _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
