Re: bio_chain: proposed solution for bio_alloc failure and large IO simplification

[Jens Axboe <axboe@suse.de>]

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