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. > 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
