Messages in this thread | | | Date | Mon, 17 Jun 2002 08:36:45 +0200 | From | Jens Axboe <> | Subject | Re: bio_chain: proposed solution for bio_alloc failure and large IO simplification |
| |
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/
| |