On Tue, May 05, 2015 at 12:19:01PM -0700, Andy Grover wrote: >> Can you explain why you want this? Right now backends in lio have a very >> simple abstraction for I/O, why do read and writes and most other >> things are built ontop of that, with a few exception for "magic" commands >> like the various discard operations. > > The goal is to pass through just SBC I/O commands to userspace, with the > rest of the commands emulated by LIO core. If you do want access to the full command pass through the full command, this means you have an existing defintion to follow. Which might not always be beatiful, but has the advantage of a) coming from the initiator in that form, (b) is a well defined standard format, and (c) doesn't require definining a new ABI for each new format. >> COMPARE_AND_WRITE is build on top of those basic operations by doing >> the reads and writes underneath, and providing synchronization in the >> core. If a backend (that is a non-passthrough) one wants to take control >> of these we need a specific hook for it instead of trying ot hack it up. > > The issue is that sbc_parse_cdb does most of what TCMU wants (set up non > I/O cmds for emulation, send us the rest) but the unwanted bit is emulating > BIDI & CAW ops as read-then-write, and sync via caw_sem. We want pure pass > through for SBC I/O ops, including BIDIs and CAW. > > See http://article.gmane.org/gmane.linux.scsi.target.devel/8689 > > Solutions? In tcmu_parse_cdb we can avoid calling sbc_parse_cdb when it > will do the wrong thing (option 1) or always call sbc_parse_cdb but fix up > when it did the wrong thing (option 2) or always call sbc_parse_cdb but fix > up later (option 3) or make CAW in TCMU work with the emulation > sbc_parse_cdb is setting up (option 4) or return an error if CAW is used > with a TCMU-backed device (option 5 (new)) or add an arg to sbc_parse_cdb > so it can avoid setting up the emulation we don't want (option 6 (new)) or > don't call sbc_parse_cdb at all and set up non-I/O cmd emulation in > tcmu_parse_cdb (option 7 (new)). > > Ilias and I thought #2 was least ugly, but what's your preference? I suspect #1 is the best option as for the reasons explained above. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
