On Wed, 3 Dec 2008 21:40:53 +0200 (EET) Kai Makisara <Kai.Makisara@xxxxxxxxxxx> wrote: > > If so, can you try this patch to convert st_int_ioctl? > > > I replaced my patch with yours. Now the tests pass. I did some tests with > debugging enabled and those showed that the sense data is returned > correctly. Great, then can I get your ACK on this patchset? > > Do you prefer me to change st_scsi_kern_execute to set -EBUSY to > > syscall_result if st_scsi_kern_execute internally fails (that is, > > blk_rq_map_kern or blk_get_request fails)? > > > I am not sure that -EBUSY is a valid error return any more. Should the > error be -ENOMEM if blk_get_request fails and otherwise return what > blk_rq_map_kern returns? > > > Note that scsi_execute_async (which st_do_scsi uses) could fail > > internally. scsi_execute_async and st_scsi_kern_execute uses the same > > functions that could fail, blk_rq_map_kern or blk_get_request > > > Yes. I am not sure that -EBUSY is correct return value there. I think that it's the right thing to return an error value to user space that scsi_execute_async returns but st_do_scsi uses has returned -EBUSY for any failure for long time so it might be safer to keep the current behavior. I'll change st_scsi_kern_execute to set -EBUSY in case of internal failure in the next submission if you prefer. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
