You also need to set byte 4 of the CDB to the allocation length (e.g. SUN_INQSIZE).
If you are in kernel context, cb_flag and callback can be set to SLEEP_FUNC, which makes life easier. You may want to pass in sizeof(scsi_arq_status) for the statuslen parameter of scsi_init_pkt so that if you get a check condition / status back you'll find out more about what the problem was. Check out "building and transporting a command" in chapter 16 of the Writing Device Drivers Guide: http://docs.sun.com/app/docs/doc/816-4854/6mb1o3agf?a Three other fields must be set after the call to scsi_init_pkt(9f): inq_pkt->pkt_private = (opaque_t)bp; inq_pkt->pkt_comp = xxcallback; inq_pkt->pkt_time = 60; Assuming you get TRAN_ACCEPT from scsi_transport(9f), your xxcallback function will get called. As scsi_pkt(9s) says: pkt_comp Specifies the command completion callback routine. When the host adapter driver has gone as far as it can in transporting a command to a SCSI target, and the command has either run to completion or can go no further for some other reason, the host adapter driver calls the function pointed to by this field and passes a pointer to the packet as argument. The callback routine itself is called from interrupt con- text and must not sleep or call any function that might sleep. So, your xxcallback function should first check pkt_reason. If you got CMD_CMPLT, check the pkt_state. If the STATE_ARQ_DONE or STATE_GOT_STATUS flags are set, there was a problem. (This is where that non-zero statuslen parameter to scsi_init_pkt would come in handy.) If that's good, next check the pkt_resid. If that is non-zero it indicates that you didn't get all of the data you asked for. In your case, it will indicate that only the first (SUN_INQSIZE - pkt->pkt_resid) bytes are valid. *Now* you can check b_un.b_addr. 8-) - Eric This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
