|| ||Kent Overstreet <email@example.com> |
|| ||firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com |
|| ||Immutable biovecs |
|| ||Wed, 27 Mar 2013 10:39:30 -0700|
|| ||firstname.lastname@example.org, email@example.com|
|| ||Article, Thread
This patch series implements immutable biovecs, and converts drivers to
the new primitives.
This is done by pulling bi_sector, bi_size and bi_idx out of struct bio
into a new iterator; to that we add bi_bvec_done which indicates the
number of bytes done in the current bvec.
This means we can create a bio that points to an arbitrary byte range in
an existing biovec; if we have a preexisting biovec that points to 4
whole pages, we can create a bio that points to the first 512 bytes of
the second bvec.
This enables easy and efficient splitting of arbitrary size bios; future
patches on top of this are going to convert the existing bio_split() in
fs/bio.c and remove the single bvec restriction.
This patch series does the necessary driver conversions so that a)
they're not modifying the biovec anymore (except whey're they've
explicitly cloned it, as in mm/bounce.c) and b) they always respect the
values of bi_idx and bi_bvec_done when the bio was passed to them - i.e.
you can submit partially completed bios to generic_make_request().
The intention is to then use this to make generic_make_request() accept
arbitrary size bios, splitting them as needed by the underlying device.
This enables a whole host of cleanups; we can get rid of merge_bvec_fn
(that's over 1000 lines of code deleted right there), bio_add_page()
becomes trivial (a lot of code becomes simpler if it doesn't have to
deal with bio_add_page() failing) - and I've also got a rewrite of the
dio code that depends on this, and shrinks direct-io.c to 650 lines,
drastically simplifying it and making it quite a bit faster too.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/