> I definitely don't buy "bio is a natural object for carrying an array > of pieces of pages"; not sure if that's what you implied in earlier > thread, but it has too much baggage from block subsystem *and* it lacks > the things we may want to associate with individual elements of such > array (starting with "how can I steal that page?" method). I think Kent is talking about what happens after the user addresses are consumed. Turning dio into more of a bio mapping and redirection engine would use more of the bio machinery instead of the bits that dio has implemented itself with state in struct dio that hangs off the bios. I imagine it'd still make sense to clean up the addresses/pages arguments that feed that engine. (And give another entry point that already has bios for callers like loop, etc.) > BTW, folks, any suggestions about the name of that "memory stream" thing? > struct iov_iter really implies iterator for iovec and more generic name > would probably be better... struct mem_stream would probably do if nobody > comes up with better variant, but it's long and somewhat clumsy... I don't like 'stream'. To me that sounds more strictly advancing than I think this'd be capable of. Maybe something dirt simple like 'mem_vec'? With 'mvec_' call prefixes? Or kiobuf! *runs* - z -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
