Mike Christie wrote: > snipped lkml and netdev. I do not think they care do they. > > James Smart wrote: >> Note: We've transitioned off topic. If what this means is "there isn't a >> good >> way except by ioctls (which still isn't easily portable) or system calls", >> then that's ok. Then at least we know the limits and can look at other >> implementation alternatives. >> > > So we have Ok for those that emailed me off list. All these interfaces have a similar problems in that the kernel cannot get enough pages to make a scatterlist that is within the HBA's limits. block/scsi_ioctl.c handles this by failing the request, sg.c handles this by preallocating buffers, the target code handles this by calling the target transfer function multiple times as James described, and using netlink as described for a target or initiator and for sg io or target commands or transport commands has similar issues if it just cannot get enough pages to make a proper scatterlist, but currently it has the extra limitation in that we are not supposed to pass pointers. Sorry for the confusion. > > 1. sysfs: prbably bad becuase to pass down every attr for the command we > need a seperate file. This does not seem like it meets the binary sysfs > file requirement. > > 2. configfs: again bad becuase we have to pass down eveyr attr for the > command in a speperate file. > > 3. ioctl: Christoph has not allowed scsi drivers to add ioctls so I > doubt he would let some other scsi code let it. > > 4. syscall: > > 5. netlink: netdev guys do not want use to pass pointers. So we either > have a worst case double copy (copy from userspace to network and > network to buffer that is within the LLDs queue limits (do like sg where > it as a preallocated buffer)) or if we used the bio code like how the > ll_rw_blk.c does just fail if the command is to large. In some cases the > io may just be too large and have to fail though. > > 5A. modify netlink to copy data to a buffer that is within some sort of > limits we can DMA from. > 5B. debate with netdev guys about passing poitners, in which case we > could have some of the problem 5 has in that when we map data we do not > have much control over the pages so we may have to drop down to a copy > to some preallocate buffer or fail model. > > 6. char device > > 7. what else... > - > : 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 - : 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
