Re: [PATCH 4/4] target: Add a user-passthrough backstore

[Alex Elsayed <eternaleye@gmail.com>]

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.