On Wed, 2008-02-06 at 18:25 -0500, Alan Stern wrote: > On Wed, 6 Feb 2008, James Bottomley wrote: > > > > What we're talking about is a routine that provides drivers a simple > > > way to access the data in a scatter-gather buffer (which may lie in > > > highmem or otherwise not be easily reachable). The idea is that some > > > commands are emulated by the driver rather than carried out by the > > > device, and the driver needs some way to stick the results in the > > > transfer buffer. > > > > Isn't that what scsi_kmap_sg() is designed for ... or do you need > > something slightly different? > > I don't know -- I've never heard of scsi_kmap_sg(). And it doesn't > appear to exist anywhere in my kernel source. > > Did you mean scsi_kmap_atomic_sg()?
Yes .. I replied from memory rather than looking in the source. > That appears to do only part of > what usb_stor_access_xfer_buf() does. In fact, all it does is map a > single page. Um, it does everything you asked about above. It's designed as a helper for SCSI devices that need to modify data for automatically generated returns (RAID devices and INQUIRY strings for instance). It's also used by some of the less well automated devices that might need to do an effective PIO feed on DMA engine halts. It allows you to address a sg list by offset and length (although it will adjust the length if there's a mapping problem). Since the only way to guarantee access to highmem is by kmap_atomic (which has limited slots), any API that does this sort of thing is necessarily page based and does single page mappings at a time. Why don't you tell me what you think is missing rather than me having to dig around in the usb sources to try to work it out. James - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
