On Wed, 2010-06-16 at 23:26 +0900, FUJITA Tomonori wrote: > On Wed, 16 Jun 2010 01:05:28 -0700 > "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> wrote: > > > On Tue, 2010-06-15 at 23:59 +0900, FUJITA Tomonori wrote: > > > On Tue, 15 Jun 2010 17:10:46 +0300 > > > "Alexander Nezhinsky" <alexandern@xxxxxxxxxxxx> wrote: > > > > > > > > Alexander, I think that you added bs_sg.c. Dropping sg and supporting > > > > > only bsg is ok for you? Or you still use this feature? > > > > > > > > It is generally ok with me. > > > > > > > > I've used bs_sg mainly for some performance measurements. > > > > As we had discussed once, it has a major drawback of not handling properly > > > > cache_sync in some scenarios, because the pass-through mode is disabled. > > > > As far as i understand, the new implementation suffers from the same problem, > > > > so it is subject to the same limitations and requires the same precautions. > > > > > > I can't recall the discussion, but the new implementation passes > > > though all the commands. So it can inform initiators of the cache mode > > > properly and pass SYNC commands to the underlying devices properly. > > > > > > > > > > The only other concern might be that if anybody uses bs_sg with real devices > > > > then the bsg-based implementation may preclude using older kernels, > > > > like 2.6.18 of RHEL5.x. > > > > > > Yeah, if there are someone who cares about sg support, supporting both > > > bsg and sg is fine by me. > > > > Hmmm, perhaps it still makes sense to support both bsg and sg following > > the previous patch then..? > > > > http://lists.wpkg.org/pipermail/stgt/2010-June/003766.html > > Ok if you are really care about sg. But Seems that the above patch > can't be applied to the current head. Can you send the updated patch? > -- Hi Tomo-san, Ok, I just resent the BSG support patch which keeps existing SG_IO code, and adds a minor fix to chk_sg_device() in order determine mode based on BSG major=254 instead of pathname. After a few quick tests both modes are now functioning as expected. Also, I included another small patch to the legacy SG_IO I have been testing to add struct sg_iovec usage support. As we don't have a hard requirement for non contigious memory in STGT backstores currently this is obviously not a hard requirement, but may be useful later. Best, --nab -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
