On Wed, Jun 08, 2016 at 09:36:15PM -0700, Nicholas A. Bellinger wrote:
> The configfs ABI should not dictate a single backend use-case.
And it doesn't. I actually had a file backend implemented to
benchmark it against the loopback driver. It needed absolutely
zero new configfs interface. And if
On Wed, 2016-06-08 at 16:12 +0300, Sagi Grimberg wrote:
> >> *) Extensible to multiple types of backend drivers.
> >>
> >> nvme-target needs a way to absorb new backend drivers, that
> >> does not effect existing configfs group layout or attributes.
> >>
> >> Looking at the nvmet/configfs layout as
On Wed, 2016-06-08 at 14:19 +0200, Christoph Hellwig wrote:
> On Tue, Jun 07, 2016 at 10:21:41PM -0700, Nicholas A. Bellinger wrote:
> > *) Extensible to multiple types of backend drivers.
> >
> > nvme-target needs a way to absorb new backend drivers, that
> > does not effect existing configfs gro
On Wed, Jun 08, 2016 at 04:12:27PM +0300, Sagi Grimberg wrote:
>> Because it keeps the code simple. If you had actually participated
>> on our development list you might have seen that until not too long
>> ago we have very fine grainded locks here. In the end Armen convinced
>> me that it's easi
*) Extensible to multiple types of backend drivers.
nvme-target needs a way to absorb new backend drivers, that
does not effect existing configfs group layout or attributes.
Looking at the nvmet/configfs layout as-is, there are no multiple
backend types defined, nor a way to control backend fe
On Tue, Jun 07, 2016 at 10:21:41PM -0700, Nicholas A. Bellinger wrote:
> *) Extensible to multiple types of backend drivers.
>
> nvme-target needs a way to absorb new backend drivers, that
> does not effect existing configfs group layout or attributes.
>
> Looking at the nvmet/configfs layout as-
On Tue, 2016-06-07 at 12:55 +0200, Christoph Hellwig wrote:
> There is absolutely no point in dragging in an overcomplicated configfs
> structure for a very simple protocol which also is very different from
> SCSI in it's nitty gritty details.
Please be more specific wrt the two individual points
On Tue, Jun 7, 2016 at 2:02 PM, Andy Grover wrote:
> On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote:
>>
>> Hi HCH & Co,
>>
>> On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote:
>>>
>>> This patch set adds a generic NVMe over Fabrics target. The
>>> implementation conforms to the NVMe
On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote:
Hi HCH & Co,
On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote:
This patch set adds a generic NVMe over Fabrics target. The
implementation conforms to the NVMe 1.2b specification (which
includes Fabrics) and provides the NVMe over Fa
There is absolutely no point in dragging in an overcomplicated configfs
structure for a very simple protocol which also is very different from
SCSI in it's nitty gritty details. Keeping the nvme target self contains
allows it to be both much simpler and much easier to understand, as well
as much
Hi HCH & Co,
On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote:
> This patch set adds a generic NVMe over Fabrics target. The
> implementation conforms to the NVMe 1.2b specification (which
> includes Fabrics) and provides the NVMe over Fabrics access
> to Linux block devices.
>
Thanks
11 matches
Mail list logo
