Hi, I had a look at your code to figure out how it works together. Here is my guess, however, probably I misunderstood several issues. In case of DMA_TO_DEVICE, your driver allocates continuous buffer and asks the hypervisor to copy data from initiator's buffer several times (= cmnd->use_sg). And then, it submits the I/O request. In case of DMA_FROM_DEVICE, your driver allocates continuous buffer and submits the I/O request. After the completion, the driver asks the hypervisor to copy data to initiator's buffer in the same way as DMA_TO_DEVICE. I think that your driver can exploit stgt easily. In case of DMA_TO_DEVICE, your driver asks stgt to create a new command and allocate sg buffer, and then copy data from initiator's buffer. After that, it asks stgt to perform the command. In case of DMA_FROM_DEVICE, your driver asks stgt to create a new command and to perform the command. After the completion notification (of course, you can specify the completion notification callback), the driver uses sg buffer in the command. stgt takes care of SCSI command handling. So your driver can focus on communication with indicators. stgt scheme to handle sense data buffer does not match your driver, however, I thought that its scheme needs to be cleaned up. So we can see it later on. We plan to do most of configurations through netlink. Your driver is purely virtual so that all configurations can be done through netlink. We've not implement all features yet, however, I think you can start to work right now. By the way, I have some questions about your driver. 1. Your driver uses bio to access non-scsi devices. I think that it leads to poor read performance. Why do you use the vfs interface to exploit page cache? 2. About task attribute, you can support only simple and ordered. You implement 'ordered task' to use bio barrier. So you don't have a complete code to handle all task attributes? stgt interface needs to be changed to support task attribute feature. I also think that we can simplify stgt_cmnd_* and buffer allocation interfaces. In short, I don't think that target drivers don't need to know or access the inside of stgt_cmnd structure. Mike, What do you think? |