Messages in this thread | | | Date | Mon, 17 Jun 2002 00:09:23 -0700 | From | Andrew Morton <> | Subject | Re: bio_chain: proposed solution for bio_alloc failure and large IO simplification |
| |
Jens Axboe wrote: > > ... > > 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.
But then bi_max is the _actual_ size of the BIO, and not the size which the caller requested.
umm, err, actually, that suits me just fine ;) We could leave bi_size as-is and just implement
unsigned bio_nr_bvecs(struct bio *bio);
But that may not work for privately allocated BIOs. "bios not coming from bio_alloc()"?
What _are_ these private BIOs, anyway? Is any in-kernel code constructing them at present?
- - 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/
| |