Eric C. Taylor wrote:
>> 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?
>
On some hardware, yes it would be. But I still need the ability to
"fake" certain requests, so in this case I still need access to the
buffer from kernel space, though for SCMD_READ and SCMD_WRITE requests I
probably do not. (In my code I have to fake inquiry, request-sense,
format, and maybe a few others.)
>
>> 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).
>
That would be nice, although it was necessarily sufficient. (Right now
in my translation layer I do the same thing, but to make tran_setup_pkt
happy, I pass an artificial dma attribute.)
> 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?
>
Either, though at the moment it is mostly the latter. (Given the
latter, I can figure out a way to make the former work.)
>
>> 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.
>
Thanks.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
