Lines Matching refs:of

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 -
14 bv_len by the number of bytes completed in that biovec.
16 In the new scheme of things, everything that must be mutated in order to
18 bi_size and bi_idx have been moved there; and instead of modifying bv_offset
19 and bv_len, struct bvec_iter has bi_bvec_done, which represents the number of
22 There are a bunch of new helper macros for hiding the gory details - in
23 particular, presenting the illusion of partially completed biovecs so that
32    instead of an integer (that corresponded to bi_idx); for a lot of code the
33    conversion just required changing the types of the arguments to
46 Having a real iterator, and making biovecs immutable, has a number of
51    which copies the contents of one bio into another. Because the biovecs
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.
67    arbitrary range of an existing biovec, both starting and ending midway
68    through biovecs. This is what enables efficient splitting of arbitrary
70    reached the end of a bio, not bi_vcnt - and the bio_iovec() macro takes
95  * Almost all usage of bi_idx is now incorrect and has been removed; instead,
97    probably passing it to one of the helper macros.
99    I.e. instead of using bio_iovec_idx() (or bio->bi_iovec[bio->bi_idx]), you
107    Secondly, when cloning a bio and reusing (a portion of) the original bio's
114    could eliminate a lot of complexity particularly in stacked drivers. Code
117    size limitations and the limitations of the underlying devices. Thus