On Tue, Jun 07 2005, Michael Christie wrote: > Quoting James Bottomley <James.Bottomley@xxxxxxxxxxxx>: > > > On Tue, 2005-06-07 at 13:10 +0100, Christoph Hellwig wrote: > > > shouldn't blk_rq_map_kern handle a 0 buffer and do nothing more than > > > blk_get_request? It's not exactly a criticial fastpath and that would make > > life > > > easier for the callers. > > > > Yes ... and it should probably do bio bouncing as well, since there's > > nothing special we have to do on completion to clean it up. > > ok. I just made it like the existing blk_rq_map_user which made the caller do > those things. I agree with Christoph, makes it nicer for blk_rq_map_user as well. I'll change the latter if you fix the former. > > I also think we might need a blk_rq_kern_iovec call that would take a > > vector of user I/O's and map it to a multiple bio request. This would > > Does it need to be a multiple bio request? A single bio should be able > to handle a request's segments and sectors limits. Indeed. > Will the user assure that the iovec will fit in a single request to > handle a case where the iovec is greater than the phys or hw segment > limits though? This is where the block layer SG_IO and the SCSI layer sg differ. The SCSI layer has historically handled these partial completion requests fine, where the block layer didn't provide functionality for it and the ide driver didn't cope with it. -- Jens Axboe - : 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
