On Tue, Aug 19, 2008 at 10:59 PM, Alexander Nezhinsky <nezhinsky at gmail.com> wrote: > On Mon, Aug 18, 2008 at 8:44 PM, Arne Redlich <agr at powerkom-dd.de> wrote: >> Am Montag, den 18.08.2008, 16:11 +1000 schrieb ronnie sahlberg: >>> >>> This patch adds support for passthrough devices to tgtd. >>> Please review/apply. >> >> Hi Ronnie, >> >> there used to be a passthrough handler - it was removed due to its >> "brokeness" (anything else besides the TMF and I_T nexus mapping >> issues?), but the commit message suggests that it [cs]hould serve as a >> starting point? >> >> http://git.kernel.org/?p=linux/kernel/git/tomo/tgt.git;a=commitdiff;h=59e4aee0796783b765e9cc5748b8f4c7efe934eb >> > > Hi, > > Could you explain why both the old pass-through handler and the new > proposed one > implement a separate device type (in addition to a new backing store)? > Why having just a separate backing store is not enough? > > We don't really introduce a new scsi device type here, do we? > It is about the way the scsi commands are delivered to the storage, so > just having > a new backing store would suffice. Do i miss something? It needs to be a new device type since the array of function pointers to the command set specific functions are registered per device type. For example mmc.c where there is a set of functions to terminate and emulate the scsi cdbs for the mmc commandset. same for the others devicetypes. Many/most of these cdb's being emulated never invoke any backend functions at all, except when reading/writing data. So a backend only would not be sufficient. I.e. for most device types, most scsi commands are never delivered to the backing store at all. they terminate in the device type emulation file. For "passthrough" one would need to only provide emulation for the REPORT LUNS cdb but pass all other commands onto the real physical device. So passthrough does need a new device type to provide the array of 256 function pointers for the cdb opcodes, one of which emulates report luns and all others just passing the cdb and data down through the ioctl() interface to sg. It would probably be possible to implement it without the need of a new backend, since this could all be implemented in the device type which could just never call any backend functions at all. I used a tiny backend in my approach since it was the easiet place to tie opening a device name into a file descriptor, ready to accept sg ioctl()s. My approach may be broken in the same way as the one removed. I however only need it to do very basic passthough so I can expose the SCSI layer onto the network with iSCSI, take network traces with wireshark and and have an easy way to compare side by side "initiator talking to genuine hardware" and "initiator talking to emulated device". And for these tests, the current one is good enough. The old one which was removed probably was too. The "boken" implementation that was removed by the patch mentioned above is much more sophisticated than my approach. Thus I would think it would be better if someone would resurrect that patch instead of using my patch if passthrough mode is required. My patch should thus not be committed to mainline. (it will continue happily to live in a separate branch in my local repository, doing the job I need it to do) ronnie s -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html |