> 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. 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. 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? 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. Is the API for this is documented in any way? 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
