[please don't drop the mailing list from the cc because others might be interested] On Mon, 2008-06-09 at 21:19 +0000, Pan, Weimin wrote: > One simple example is a router. If I want to router data from one > interface (front-end) to another (back-end), I only need to know where > the data is (physical memory address DMAed in). I can pass this > address to another interface driver to move the data out (DMAed out). There's not really such thing as a "router" use for the SCSI mid-layer. The closest we come is the target infrastructure. For user space implementations like STGT there's no choice, the vma is what you have to hang the implementation on. For kernel implementations like SCST you can get away without having any mappings. > But I like to put the command process in user space. So I only need to > know where the data is (from ioctl) and pass this to sg driver (for > example). Right now, I can pass a S/G list to sg but sg driver assumes > it is a virtual memory address list. I don't mind to write a new upper > layer driver to handle physical address S/G instead of user space > virtual address S/G. But I don't want to change middle layer and LLD > interface. I saw middler layer passes scatterlist to LLD. But LLD > always assumes the scatterlist's page_link is set and dma_address is > not set. Is it possible that I set up dma_address=phy memory address > and page_link=0? I just don't understand why SCSI subsystem doesn't > clearly define this usage model. Then you want to look at how STGT does it (in fact, you probably want to be using STGT because that's the way it was designed). However, there's no getting away from the need for a user space mapping for the data in that case. On the flip side, there's not a huge performance overhead having the mapping set up. If you don't have a mapping somewhere, the pages aren't pinned in the page cache and may be reused. James -- 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
