On Sun, 2008-02-17 at 23:52 +0900, FUJITA Tomonori wrote: > On Sun, 17 Feb 2008 07:28:48 -0700 > Matthew Wilcox <matthew@xxxxxx> wrote: > > > On Sun, Feb 17, 2008 at 08:18:11AM -0600, James Bottomley wrote: > > > No, he means that kmap_atomic can only map a page of data. This makes > > > single page only sg list entries and input assumption into this loop. > > > with ENABLE_CLUSTERING, that's potentially not true. Of course, this > > > accidentally works most of the time because of the way kmap functions. > > > > Ah, right. I'm on the verge of releasing a ram-based scsi driver I've > > been working on ... this loop should work fine with clustering as it > > takes account of the sg potentially having multiple pages: > > > > scsi_for_each_sg(cmnd, sg, scsi_sg_count(cmnd), i) { > > struct page *sgpage = sg_page(sg); > > unsigned int to_off = sg->offset; > > unsigned int sg_copy = sg->length; > > if (sg_copy > len) > > sg_copy = len; > > len -= sg_copy; > > stex driver has a similar function to copies data between a buffer and > a scatter list. I think that scsi_kmap_atomic_sg is a bit primitive > (and not very popular). I'll send a patch to add a helper function to > scsi_lib.c that copies data between a buffer and a scatter list. It > would be useful for several drivers. Actually, if you're going to sweep up them all, libata also does this. However, mapping and copying data isn't a SCSI specific function, it's one any virtual block driver should do, so I think block might be the correct location for such a function. James - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html