On Sat, Jun 15 2002, Andrew Morton wrote:
> "Adam J. Richter" wrote:
> >
> > ...
> > newbio = q->one_more_bvec(q, bio, page, offset, len);
> >
>
> That's a comfortable interface. Or maybe just:
>
> struct bio *bio_add_bvec(bio, page, offset, len);
I agree, that's the interface that I want.
> Couple of points:
>
> - It's tricky to determine how many bvecs are available in
> a bio. There is no straightforward "how big is it" field
> in struct bio.
That's true. It's trivial for bios coming out of bio pools, for
privately allocated ones it gets a bit worse. Should not be hard to
clean up, though.
> - AFAIK, there are no established conventions for BIO assembly.
> We have conventions which state what the various fields do
> while the BIO is being processed by the block layer, but not
> for when the client is assembling the BIO.
>
> What I did, and what I'd suggest as a convention is:
>
> During BIO assembly, bi_vcnt indicates the maximum number of
> bvecs which the BIO can hold. And bi_idx indexes the next-free
> bvec within the BIO.
Hmm I don't like that too much. For reference, bi_vcnt from the block
layer is the number of bio_vecs in the bio. And bi_idx is the index into
the 'current' bio_vec. To tie that in with the above, how about just
changing bi_max to be a real number. Internal bio can still find the
pool from that, and private bios can just fill it out.
-- Jens Axboe- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:12 EST