Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752107AbdHHHXO (ORCPT ); Tue, 8 Aug 2017 03:23:14 -0400 Received: from mga11.intel.com ([192.55.52.93]:14220 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751880AbdHHHXM (ORCPT ); Tue, 8 Aug 2017 03:23:12 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,342,1498546800"; d="scan'208";a="1001209020" Date: Tue, 8 Aug 2017 03:29:52 -0400 From: Keith Busch To: Sreekanth Reddy Cc: James Bottomley , Kashyap Desai , Christoph Hellwig , Hannes Reinecke , "linux-scsi@vger.kernel.org" , Chaitra Basappa , Suganath Prabu Subramani , Sathya Prakash Veerichetty , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, "Martin K. Petersen" Subject: Re: [PATCH v2 00/13] mpt3sas driver NVMe support: Message-ID: <20170808072952.GB9938@localhost.localdomain> References: <1500038560-11231-1-git-send-email-suganath-prabu.subramani@broadcom.com> <20170805135353.GA7526@infradead.org> <1501944129.3649.9.camel@HansenPartnership.com> <0ada8680ebfeb026662d858ec2b38ef4@mail.gmail.com> <1502115492.2841.20.camel@HansenPartnership.com> <1502120725.2841.28.camel@HansenPartnership.com> <20170808040449.GE842@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 653 Lines: 13 On Tue, Aug 08, 2017 at 12:33:40PM +0530, Sreekanth Reddy wrote: > On Tue, Aug 8, 2017 at 9:34 AM, Keith Busch wrote: > > > > It looks like they can make existing nvme tooling work with little > > effort if they have the driver implement NVME_IOCTL_ADMIN_COMMAND, and > > Precisely, I was thinking on the same line and you clarified. I will > spend sometime on this and get back to you. Sounds good. Just note that while the majority of NVMe management should be reachable with just that IOCTL, some tooling features may not work correctly since they look for /dev/nvmeX, and I assume this driver will create /dev/sdX instead.