From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754584AbcFGKzy (ORCPT ); Tue, 7 Jun 2016 06:55:54 -0400 Received: from verein.lst.de ([213.95.11.211]:44330 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754012AbcFGKzw (ORCPT ); Tue, 7 Jun 2016 06:55:52 -0400 Date: Tue, 7 Jun 2016 12:55:50 +0200 From: Christoph Hellwig To: "Nicholas A. Bellinger" Cc: Christoph Hellwig , axboe@kernel.dk, keith.busch@intel.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, target-devel , linux-scsi Subject: Re: NVMe over Fabrics target implementation Message-ID: <20160607105550.GB17113@lst.de> References: <1465248177-17970-1-git-send-email-hch@lst.de> <1465280632.5365.58.camel@haakon3.risingtidesystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1465280632.5365.58.camel@haakon3.risingtidesystems.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 better testable - see the amount of test coverage we could easily add for example. Or to put it the other way around - if there was any major synergy in reusing the SCSI target code that just shows we're missing functionality in the block layer or configfs. The only thing where this is the case mid-term is persistent reservations, but Mike Christie already has a plan for a pluggable PR API, which I'm very interested in.