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. Nick, do you still want this patch? I guess that you prefer sg now since bsg doesn't support iovec. > As an alternative i could suggest having both bs_sg3 (old code) and > bs_sg4 (new code), and compiling them in (both or sg3 only) conditioned on > a makefile flag like "make SG3=1". > > A side question: is BSG documented anywhere? No. I'll add it to my todo list. > I have read the kernel module's source, and it looks that it depends on > support for executing scsi commands in some layers below, > within the block subsystem. bsg doesn't expect a device to support SCSI commands. You can create bsg devices for non SCSI devices. > Is the API for this is documented in any way? Not. The existing bsg users in mainline shows how the API works. > I could not find any docs or discussions, only some patch > submissions for BSG. -- 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
