Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754071AbcLFRM2 (ORCPT ); Tue, 6 Dec 2016 12:12:28 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:58449 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752028AbcLFRMZ (ORCPT ); Tue, 6 Dec 2016 12:12:25 -0500 Date: Tue, 6 Dec 2016 09:12:13 -0800 From: Christoph Hellwig To: Jason Gunthorpe Cc: Stephen Bates , Dan Williams , Logan Gunthorpe , Haggai Eran , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "linux-nvdimm@ml01.01.org" , "christian.koenig@amd.com" , "Suravee.Suthikulpanit@amd.com" , "John.Bridgman@amd.com" , "Alexander.Deucher@amd.com" , "Linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Max Gurtovoy , "linux-pci@vger.kernel.org" , "serguei.sagalovitch@amd.com" , "Paul.Blinzer@amd.com" , "Felix.Kuehling@amd.com" , "ben.sander@amd.com" Subject: Re: Enabling peer to peer device transactions for PCIe devices Message-ID: <20161206171213.GA870@infradead.org> References: <61a2fb07344aacd81111449d222de66e.squirrel@webmail.raithlin.com> <20161205171830.GB27784@obsidianresearch.com> <20161205180231.GA28133@obsidianresearch.com> <20161206163850.GC28066@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161206163850.GC28066@obsidianresearch.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 815 Lines: 15 On Tue, Dec 06, 2016 at 09:38:50AM -0700, Jason Gunthorpe wrote: > > > I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial > > > to accomplish in sysfs through /sys/dev/char to find the sysfs path of the > > > device-dax instance under the nvme device, or if you already have the nvme > > > sysfs path the dax instance(s) will appear under the "dax" sub-directory. > > > > Personally I think mapping the dax resource in the sysfs tree is a nice > > way to do this and a bit more intuitive than mapping a /dev/nvmeX. > > It is still not at all clear to me what userpsace is supposed to do > with this on nvme.. How is the CMB usable from userspace? I don't think trying to expose it to userspace makes any sense. Exposing it to in-kernel storage targets on the other hand makes a lot of sense.