On Thu, Jul 26, 2012 at 10:30 PM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > On 07/26/2012 04:57 PM, Peng Tao wrote: > >> On Thu, Jul 26, 2012 at 8:16 PM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: >>> On 07/26/2012 11:25 AM, Peng Tao wrote: >>> >>>> For these two sectors, I need to allocate two pages... Just look at >>>> struct bio_vec. >>>> >>> >>> >>> NO! I know all about bio_vecs >>> >>> You need 1024 bytes, and 2 x one entry BIOs which is a few bytes, where >>> did you get the "two pages" from? >>> >> What do you put int bio_vec->bv_page? Even if you just use 512 bytes >> of a page, it is still allocated page. >> > > > No!! > > You just use bio_map_kern or in one go blk_rq_map_kern() with any: kmalloc, > stack, or kernel pointer. And that's that. It will take what it will take. > First I should admit I don't know bio_map_kern() alike. Thanks for teaching me about them (see, here is your credit :) Looking at them, I don't think it is proper to use them in block layout code, mainly because It is a layer violation. Searching for callers of io_map_kern/blk_rq_map_kern(), they are either block core code or device drivers. Clearly these interfaces are block layer internal APIs and file systems shouldn't touch them. Therefore I still think I should stick with plain common bio_alloc/bio_add_page/submit_bio interfaces. Thanks for the suggestion. Cheers, Tao -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
