Lines Matching refs:a

7 As of 3.13, biovecs should never be modified after a bio has been submitted.
8 Instead, we have a new struct bvec_iter which represents a range of a biovec -
11 More specifically, old code that needed to partially complete a bio would
13 ended up partway through a biovec, it would increment bv_offset and decrement
17 partially complete a bio is segregated into struct bvec_iter: bi_sector,
22 There are a bunch of new helper macros for hiding the gory details - in
31    bio_for_each_segment() has been updated to take a bvec_iter argument
32    instead of an integer (that corresponded to bi_idx); for a lot of code the
36  * Advancing a bvec_iter is done with bio_advance_iter(); bio_advance() is a
40    There is a lower level advance function - bvec_iter_advance() - which takes
41    a pointer to a biovec, not a bio; this is used by the bio integrity code.
46 Having a real iterator, and making biovecs immutable, has a number of
50    exactly one bvec at a time - for example, bio_copy_data() in fs/bio.c,
56    The new code is much more straightforward - have a look. This sort of
57    pattern comes up in a lot of places; a lot of drivers were essentially open
59    simplifies a lot of code.
64    - again, this was being done in a fair number of places.
66  * Biovecs can be shared between multiple bios - a bvec iter can represent an
70    reached the end of a bio, not bi_vcnt - and the bio_iovec() macro takes
74    bios with more than a single bvec! Now, we can efficiently split arbitrary
85    It used to be the case that submitting a partially completed bio would work
96    where previously you would have used bi_idx you'd now use a bvec_iter,
100    now use bio_iter_iovec(), which takes a bvec_iter and returns a
107    Secondly, when cloning a bio and reusing (a portion of) the original bio's