Re: [RFC PATCH 0/4] iov_iter: Add composite, scatterlist and skbuff iterator types

[Christoph Hellwig <hch@infradead.org>]

This is going entirely in the wrong direction.  We don't need more iter
types but less.  The reason why we have to many is because the underlying
representation of the ranges is a mess which goes deeper than just the
iterator, because it also means we have to convert between the
underlying representations all the time.

E.g. the socket code should have (and either has for a while or at least
there were patches) been using bio_vecs instead of reinventing them as sk
fragment.  The crypto code should not be using scatterlists, which are a
horrible data structure because they mix up the physical memory
description and the dma mapping information which isn't even used for
most uses, etc.

So instead of more iters let's convert everyone to a common
scatter/gather memory definition, which simplifies the iters.  For now
that is the bio_vec, which really should be converted from storing a
struct page to a phys_addr_t (and maybe renamed if that helps adoption).
That allows to trivially kill the kvec for example.

As for the head/tail - that seems to be a odd NFS/sunrpc fetish.  I've
actually started a little project to just convert the sunrpc code to
use bio_vecs, which massively simplifies the code, and allows directly
passing it to the iters in the socket API.  It doesn't quite work yet
but shows how all these custom (and in this case rather ad-hoc) memory
fragment representation cause a huge mess.

I don't think the iterlist can work in practice, but it would be nice
to have for a few use cases.  If it worked it should hopefully allow
to kill off the odd xarray iterator.