On Wed, 11 Feb 2009 17:07:16 +0200 Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > FUJITA Tomonori wrote: > > On Wed, 11 Feb 2009 16:52:37 +0200 > > Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > > > >> FUJITA Tomonori wrote: > >>> On Wed, 11 Feb 2009 11:15:53 +0200 > >>> Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > >>> > >>>> I spoke too soon. There is one more place that uses blk_rq_append_bio, that is > >>>> the place that adds the read/write bio that is received in osd_req_write/read. > >>>> The reason I receive a bio at these is because mainly I need a way to > >>>> accept struct page* arrays, as well as kernel & user pointers. A bio is a nice > >>> The API using an array of pointers to page can handle everything. So > >>> why do the users of ULD (some rare file systems, I guess), osd > >>> initiator, need to build bios and pass them? > >>> > >>> > >>>> general carrier for any type of memory. Given a bio at hand there are no ways > >>>> left to prepare a request from it save the FS generic_make_request() route. > >>>> > >>>> I was thinking of using struct sg_iovec* at one stage but they look very > >>>> scary when used with page*, and mapping a page to a pointer but not doing > >>>> cache sync and all that jazz. A bio is a very nice carrier of a scatter-gather > >>>> list of memory. It has all the API for any needs. blk_rq_append_bio() was the last > >>>> way to associate a bio with a request. (except for privileged block-filesystems) > >>> We need to remove the usage of blk_rq_append_bio() in scsi. > >>> > >>> > >>>> So the first thing we have to decide is what API we need at read/write > >>>> today there is: > >>> You are talking about the API for osd file systems (or something > >>> related with osd), right? If so, I think that you can do whatever you > >>> want to do now. You can make a mistake since it's in-kernel API. > >>> > >>> > >>>> void osd_req_read(struct osd_request *or, > >>>> const struct osd_obj_id *, struct bio *data_in, u64 offset); > >>>> > >>>> in exofs I use these two: > >>>> > >>>> int osd_req_read_kern(struct osd_request *or, > >>>> const struct osd_obj_id *obj, u64 offset, void *buff, u64 len); > >>>> int osd_req_read_pages(struct osd_request *or, > >>>> const struct osd_obj_id *, u64 offset, u64 length, > >>>> struct page **pages, int page_count); > >>>> > >>> As I wrote above, if you have an interface handling 'struct page > >>> **pages', then there should be ok. > >> Sorry you miss understand me, I did not explain well. > >> > >> int osd_req_read_pages(,,,, struct page **pages, int page_count); > >> > >> Is in exofs.ko. It builds a bio out of **pages then calls > >> osd_req_read(,,bio,) which will then call blk_rq_append_bio() > > > > As I wrote in the previous mail, why does exofs need to build a bio? > > Why can exofs pass pages to osd ULD? > > > > > > Sure it can pass pages to ULD but then how ULD maks a request out of > pages? If you extend blk_rq_map_kern as James did, your ULD make a request out of passed pages, that is, the block layer properly builds a request with bio(s). I think that another possible option is adding a new mapping function that can handle multiple bios for kernel buffers (as Mike extended blk_rq_map_user). > And it gets more complicated then that (above multiple times) I don't think so. If you don't have time to work on it, please let me know. I'll fix OSD ULD. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
