Am Monday 26 January 2009 22:43:09 schrieb Sarah Sharp: > If the driver is blocked waiting on the scatter gather transfer by calling > usb_sg_wait(), it obviously can't queue any other commands. The question is, > should the driver spawn a kernel thread or a work queue or something, so that > each instance can call usb_sg_init() and usb_sg_wait()? Or should the USB core > API be changed so that the driver can submit multiple URBs with scatter gather > list pointers in them? sg_complete() could simply be changed to use wake_up() Secondly you can already submit more than one sg request. You just have to wait for completion at one point. > A more important question is will the SCSI layer can support command queueing > to the USB MSD driver, or will there need to be changes there also? SCSI is fine. I would suggest that at this point the model of a kernel thread per device becomes a problem, not an asset. Submitting request from queuecommand() and calling scsi_done() in the completion handlers from interrupt context seems to be the simpler way. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
