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.
>
I'm talking about using tran_setup_pkt, instead of tran_init_pkt.
Its a much simpler API. As long as you are happy with DMA cookies, and
don't need to map in the bp's yourself.
> 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.
>
Yes, I saw that. scsa1394 looks like the poster child for why those two
PSARC cases exist. (Code to do special kmem_cache optimization, and DMA
mapping logic.)
I'm pretty sure that scsi_pkt2bp() is what I need.
-- Garrett
> -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
