On 02/03/2014 09:12 AM, Christoph Hellwig wrote: > On Sat, Feb 01, 2014 at 10:43:01PM +0000, Al Viro wrote: >> * WTF bother passing 'pos' separately? It's the same mistake that was >> made with ->aio_read/->aio_write and just as with those, *all* callers >> provably have pos == iocb->ki_pos. > > I think this landed with the initial aio support, which planned for > allowing AIO retries for a workqueue with a partially incremented > pos. None of this ever got merged, probably because it was too ugly > to live. Yeah, when these patches were first written, AIO looked a lot different. >> * We *definitely* want a variant structure with tag - unsigned long thing >> was just plain insane. I see at least two variants - array of iovecs >> and array of (at least) triples <page, offset, length>. Quite possibly - >> quadruples, with "here's how to try to steal this page" thrown in, if >> we want that as replacement for ->splice_write() as well (it looks like >> the few instances that do steal on pipe-to-file splices could be dealt >> with the same way as the dumb ones, provided that ->write_iter or whatever >> we end up calling it is allowed to try and steal pages). Possibly more >> variants on the read side of things... FWIW, I'm not sure that bio_vec >> makes a lot of sense here. > > bio_vec just is one of the many page+offset+len containers we have, I > guess Dave took it because loop uses it. We could either invent a new > one here or finally have a common one for the different uses all over > the kernel. With Kent's immutable bio_vec changes, peeking inside the bio to get to the bio_vec is uglier than it was before, so there's no need to stick with that. Shaggy -- 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
