> So, > > Looking at the SCSA code, it looks like there is a "new" API for DMA and > packet initialization. In particular, scsi_tran_setup_pkt(), when used > with the kmem_cache, also does the work to do the DMA initialization, > binding, etc. that HBA drivers are normally burdened with. (This > appears to be part of PSARC 2006/240. There is also 2005/680, but that > seems obsoleted by 2006/240.)
Right. > This is a good thing, since the code is pretty much the same with only > the dma attribute structure for a difference. > > There is one wrinkle however. I may need to access the associated buf > (bp) for a packet instead of passing it off for DMA. This is necessary > f the HBA has to fall back to PIO, or if the driver needs to "fake" a > SCSI transaction. The wrinkle here is that none of > the entry points directly take a bp anymore. Even tran_start() > doesn't get the bp. I take it the HBA may need to fall back to PIO on certain models of hardware, which would be known at attach time. Is that correct? > OpenGrok finds me a routine called "scsi_pkt2bp()", which, IIUC, I > should be able to use. (Along with bp_mapin().) However, I can find > o* callers for this code (maybe in usr/closed? I couldn't find any), > and there is no man page for the code. I had used this ealier in some prototyping, but ended up not needing it. > So I want to use the function. Its in ON. Why isn't it documented? > Should I file a fast-track to open it? Or should another approach be used? I had created a version which would interpret a NULL dma attributes as "no dma," so the framework would do the mapin. I was using this for a new version of the iscsi initiator (which doesn't use dma). When you say "fake a scsi transaction," do you mean it needs to send an internally generated command to the device, or do you mean it needs to fake up a response to a scsi command it received? > Btw, the man pages surrounding tran_setup_pkt() are bit sketchy on > details, and make a bogus reference to tran_setup_bp() (It looks like > that is left over from 2005/680, but was removed in the code but not the > man pages in 2006/240.). I think there is some opportunity to improve > the docs, at least. Okay. - Eric This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
