Nicholas A. Bellinger wrote: <snip> > So the idea of allowing the in-kernel CDB emulation to run after > user-space has returned unsupported opcode is problematic for a couple > of different reasons. > > First, if the correct feature bits in standard INQUIRY + EVPD INQUIRY, > etc are not populated by user-space to match what in-kernel CDB > emulation actually supports, this can result in potentially undefined > results initiator side. > > Also for example, if user-space decided to emulate only a subset of PR > operations, and leaves the rest of it up to the in-kernel emulation, > there's not really a way to sync current state between the two, which > also can end up with undefined results. > > So that said, I think a saner approach would be two define two modes of > operation for TCMU: > > *) Passthrough Mode: All CDBs are passed to user-space, and no > in-kernel emulation is done in the event of an unsupported > opcode response. > > *) I/O Mode: I/O related CDBs are passed into user-space, but > all control CDBs continue to be processed by in-kernel emulation. > This effectively limits operation to TYPE_DISK, but with this mode > it's probably OK to assume this. > > This seems like the best trade-off between flexibility when everything > should be handled by user-space, vs. functionality when only block > remapping of I/O is occurring in user-space code. The problem there is that the first case has all the issues of pscsi and simply becomes a performance optimization over tgt+iscsi client+pscsi and the latter case excludes the main use cases I'm interested in - OSDs, media changers, optical discs (the biggest thing for me), and so forth. One of the main things I want to do with this is hook up a plugin that uses libmirage to handle various optical disc image formats. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
