Re: [LSF/MM/BPF TOPIC] block drivers in user space

From: Sagi Grimberg <sagi@grimberg.me>
To: Christoph Hellwig <hch@infradead.org>
Cc: Hannes Reinecke <hare@suse.de>,
	Bart Van Assche <bvanassche@acm.org>,
	Mike Christie <michael.christie@oracle.com>,
	Gabriel Krisman Bertazi <krisman@collabora.com>,
	lsf-pc@lists.linux-foundation.org, linux-block@vger.kernel.org
Subject: Re: [LSF/MM/BPF TOPIC] block drivers in user space
Date: Tue, 15 Mar 2022 10:38:24 +0200	[thread overview]
Message-ID: <1cec32d1-511e-1a78-b157-9ecaebc72c66@grimberg.me> (raw)
In-Reply-To: <YjBKaoBYtofJXrgw@infradead.org>

> 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...