Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755962AbbLDMQ0 (ORCPT ); Fri, 4 Dec 2015 07:16:26 -0500 Received: from mail-wm0-f42.google.com ([74.125.82.42]:34144 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752623AbbLDMQY (ORCPT ); Fri, 4 Dec 2015 07:16:24 -0500 Subject: Re: linux-next: build failure after merge of the block tree To: Christoph Hellwig References: <20151202161936.22b23668cf9dea9872b5079b@kernel.org> <20151202164527.GA31048@lst.de> <565F5D96.5050902@kernel.dk> <565FFFA5.6000003@bjorling.me> <20151203090638.GA14329@lst.de> <566010EE.6050806@bjorling.me> <20151203095726.GA15428@lst.de> <566014BF.3080702@bjorling.me> <20151203102132.GA15905@lst.de> <5660226B.5070800@bjorling.me> <20151203164259.GA14678@lst.de> Cc: Jens Axboe , Mark Brown , Keith Busch , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org From: =?UTF-8?Q?Matias_Bj=c3=b8rling?= Organization: Paletta Message-ID: <56618415.3010405@bjorling.me> Date: Fri, 4 Dec 2015 13:16:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151203164259.GA14678@lst.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1835 Lines: 37 On 12/03/2015 05:42 PM, Christoph Hellwig wrote: > On Thu, Dec 03, 2015 at 12:07:23PM +0100, Matias Bj?rling wrote: >> What is the reason to keep the nvme_ns internally to the nvme core? >> >> We can definitely move ->nsid and the lba_shift into nvm_dev. Only thing I >> have is that it moves a small part of nvme logic into the lightnvm core. > > It's a structure specific to the NVM command set, and the block device > use to implement it in Linux. Similar to how you wouldn't use the SCSI > disk driver data structures to implement the tape driver for example. > Granted. Taking a step back and see how it would look in the specification. For that case, the identify geometry should properly replace the identify namespace command and extend the controller identify with a method to expose identify geometry structures. It falls back to that we don't have the appropriate bits in the specification (as there isn't a vendor specific command set (CSS) place at the moment). I'll rather not (and patches properly won't be accepted) push specific meanings to reserved bits in the standard, which then is overruled by vendor specific pci id's. The NVMe and LightNVM still shares some common ground as I/O submission/completion still follows normal I/O submissions. The Submission/Completion sizes (SQES/CQES), ONCS bits, number of namespaces could properly be either abstracted or duplicated in vendor specific bits. I'll work on getting ->nsid, and lba_shift abstracted away. However, the best solution will be to get some bits in the spec and implement it appropriately. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/