On Wed, Mar 03 2010, Dmitry Monakhov wrote: > Mike Snitzer <snitzer@xxxxxxxxxx> writes: > > > Linux has all sorts of internal interfaces that are "odd"... the current > > 'q->merge_bvec_fn' interface included. But odd is not a problem (nor is > > it "broken") unless you make changes that don't consider how the current > > interface is defined. > Ok. then cant you please explain more historical questions > 1) Why bio_add_page() can not add less data than requested? > Seems that it doesn't make caller's code much complicate > Off course barrier bio is special case. I don't consider it here. Because the caller may not expect that, a partial add may not make any sense to the caller. The bio code obviously doesn't care. And it certainly could complicate the caller a lot, if they need to now issue and wait for several bio's instead of just a single one. Now a single completion queue and wait_for_completion() is not enough. > 2) What statement "bio_add_page() must accept at least one page" > exactly means? > IMHO this means that bio_add_page() must accept at least > one page with len (PAGE_SIZE - offset). Or more restricted > statemnt that first bio_add_page() must be always successfull. It's really 'first add must succeed', the restriction being that you cannot rely on that first add being more than a single page. So the rule is that you must accept at least a page at any offset if the bio is currently empty, since we know that a page is typically our IO granularity. > But currently in some places this rule treated as what all bio > which has size less whan PAGE_SIZE are accepted. And in x86 such > bio may has up to 8 pages/bvecs. Not sure I follow what you are trying to say here. -- Jens Axboe -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
