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 I will be supporting BSG and SG in the QEMU-KVM tree, so perhaps we should be doing the same here for STGT..? > > Nick, do you still want this patch? I guess that you prefer sg now > since bsg doesn't support iovec. > At least with STGT userspace I would still prefer BSG when available on the host for TCM_Loop Ports, et al. Also, note that both revs of my BSG patch for STGT are actually not using iovecs because we are dealing with contigious userspace memory from STGT obtained via scsi_get_[out,in]_buffer() and not userspace scatterlist memory so there is not a hard requirement for them. 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
