FYI, I have absolutely no interest in supporting any userspace hooks
in nvmet.
Don't think we are discussing adding anything specific to nvmet, a
userspace backend will most likely sit behind a block device exported
via nvmet (at least from my perspective). Although I do see issues
with using the passthru interface...
If you want a userspace nvme implementation please use SPDK.
The original use-case did not include nvmet, I may have stirred
the pot saying that we have nvmet loopback instead of a new kind
of device with a new set of tools.
I don't think that spdk meets even the original android use-case.
Not touching nvmet is fine, it just eliminates some of the possible
use-cases. Although personally I don't see a huge issue with adding
yet another backend to nvmet...
After discussing with google for the r/w/flush use-case (cloud, not
android), they are interested in avoiding the source of complexity that
arises from implementing the NVMe protocol in the interface. Even if it
is hidden behind a userspace library, it means converting block
rq->nvme->block rq, which might have a performance impact?
From your previous message, I think we can move forward with dissociating
the original use case from nvme passthrough, and have the userspace hook
as a block driver?
Yes, there is no desire to do that.
