Dan Mick wrote:
> Artem Kachitchkine 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
>>> if 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'm confused. Or maybe you're confused... :) tran_init_pkt takes bp.
>>
>
> tran_setup_pkt (there is no scsi_tran_setup_pkt) is an optional HBA entry
> point,
> and doesn't take a bp. The manpage doesn't make it very clear, but the code
> implies that if you have a tran_setup_pkt, you must not have a tran_init_pkt,
> that is, it ASSERT()s to that effect. (the manpage merely says that
> tran_setup_pkt is an "alternative".)
>
> but if you're using tran_setup_pkt instead of tran_init_pkt, it doesn't
> appear
> as though you get a bp, no, and I don't know what the answer is.
>
Right. And the reason for this, I think, is to free device drivers (HBA
drivers) from having to worry about all the DMA related logic for SCSI.
(I.e. figuring out the PKT_PARTIAL, and handling both limited
scatter/gather lists on hardware as well as limited resources from the
host platform. You wind up doing a dance with both multiple DMA cookies
and multiple DMA windows.)
The code in WDD is instructive here. :-)
So tran_setup_pkt() basically does all this for you, plus gives you a
kmem_cache so that you don't wind up reallocating DMA handles, etc. for
each SCSI transaction. It looks, at least on the face of it, like this
is a fair win.
Btw, my SCSI translation layer for generic block devices (such as
SDcard) is about done. I'll be writing up a PSARC proposal for it this
week. (The only thing I haven't done yet is make sure that it does the
right thing w.r.t. hotplug.)
-- Garrett
>
>> E.g. scsa1394: we bp_mapin() in scsa1394_scsi_init_pkt() and save bp
>> pointer in the private command structure scsa1394_cmd_t, which in turn
>> hangs off of scsi_pkt->pkt_ha_private - which is how functions like
>> tran_start get to it. We bp_mapout() in scsa1394_scsi_destroy_pkt(). In
>> between, the driver simply references memory pointed by bp->b_un.b_addr.
>>
>> -Artem
>>
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
