Adar Dembo wrote:
When sending SG_IO ioctls to a device: - /dev/sgX devices (using sg.c) follow the behavior described at http://tldp.org/HOWTO/SCSI-Generic-HOWTO/dio.html in terms of defaulting to indirect I/O, and using direct I/O only if both /proc/scsi/sg/allow_dio and SG_FLAG_DIRECT_IO in the request are set. - /dev/srX devices (using sr.c) default to direct I/O. At least, that appears to be the case from inspecting the code, as sr_block_ioctl->cdrom_ioctl->scsi_cmd_ioctl->sg_io->blk_rq_map_user->__blk_rq_map_user will attempt to map the pages, regardless of what the user specified in the request or in the proc node. This difference caught me by surprise; my expectation would be that an sg_io_hdr_t passed via SG_IO would be serviced in the same way regardless of the underlying driver. Is this a bug, or a feature? If the latter, is it documented somewhere?
As the name suggests the SG_IO ioctl was originally implemented in the sg driver. Due to difficulties in discovering which sg device corresponded to a particular SCSI device node belonging to another driver (e.g. /dev/sr0 belonging to the sr driver), the SG_IO ioctl was grafted on to various other drivers (in some cases via the block layer). The result is not always pretty and there are many subtle differences. There is no 100% clean SCSI pass-through in Linux (and if there was it could not easily share a device with another high level SCSI driver such as sr). The sg and the bsg drivers give the cleanest pass-throughs. The rest tend to make assumptions appropriate to their class of devices. And it is not just the SG_IO ioctl that you need to take care of: some other drivers will hang on open() if the device is not ready and the O_NONBLOCK flag is not given. Summary: the driver "owning" the file descriptor that the SG_IO ioctl uses, is in control. Doug Gilbert -- 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
