Eric C. Taylor wrote:
>>>> 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?
>>
>> 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.)
>>
>
> If you need to do that then promoting scsi_pkt2bp would probably
> be the thing to do (or, better yet, come up with some sort of abstraction
> so that HBA drivers only get access to a subset of the buf structure).
>
I think I'm willing to live with this as a consolidation private
interface for now. Alternatively,
one can imagine having a routine called "scsi_pkt_mapin(struct scsi_pkt
*, caddr_t *, size_t *)",
that maps in the associated buf, and gives back the address and size of
the associated buf.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
