On 07/26/2012 06:30 PM, Peng Tao wrote: > 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. > Crap no!!! bio_kmalloc/bio_map_kern/submit_bio is just fine. Same exact layer. same exact BIO API level. You can mix and match bio_map_kern chained with any bio_add_page and submit one chain or let the elevator chain them with plug unplug they are all the same. If you have pages - bio_add_page; Have pointers - bio_map_kern. They are used all over libosd exofs ore scsi_lib and what not. Any user of block layer, which is what block layout is! Again some Credit Boaz > > 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
