From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030659AbdDSSTt (ORCPT ); Wed, 19 Apr 2017 14:19:49 -0400 Received: from ale.deltatee.com ([207.54.116.67]:57906 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S968889AbdDSSTm (ORCPT ); Wed, 19 Apr 2017 14:19:42 -0400 To: Dan Williams , Jerome Glisse References: <20170418164557.GA7181@obsidianresearch.com> <20170418190138.GH7181@obsidianresearch.com> <20170418210339.GA24257@obsidianresearch.com> <1492564806.25766.124.camel@kernel.crashing.org> <20170419155557.GA8497@obsidianresearch.com> <4899b011-bdfb-18d8-ef00-33a1516216a6@deltatee.com> <20170419173225.GA11255@redhat.com> Cc: Jens Axboe , Keith Busch , "James E.J. Bottomley" , "Martin K. Petersen" , linux-rdma@vger.kernel.org, Benjamin Herrenschmidt , Steve Wise , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, Jason Gunthorpe , Bjorn Helgaas , linux-pci@vger.kernel.org, linux-nvdimm , Max Gurtovoy , linux-scsi , Christoph Hellwig From: Logan Gunthorpe Message-ID: <99a22044-8f15-f381-19ee-e239e9d2da29@deltatee.com> Date: Wed, 19 Apr 2017 12:19:32 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.111 X-SA-Exim-Rcpt-To: hch@lst.de, linux-scsi@vger.kernel.org, maxg@mellanox.com, linux-nvdimm@ml01.01.org, linux-pci@vger.kernel.org, helgaas@kernel.org, jgunthorpe@obsidianresearch.com, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, swise@opengridcomputing.com, benh@kernel.crashing.org, linux-rdma@vger.kernel.org, martin.petersen@oracle.com, jejb@linux.vnet.ibm.com, keith.busch@intel.com, axboe@kernel.dk, jglisse@redhat.com, dan.j.williams@intel.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19/04/17 12:11 PM, Logan Gunthorpe wrote: > > > On 19/04/17 11:41 AM, Dan Williams wrote: >> No, not quite ;-). I still don't think we should require the non-HMM >> to pass NULL for all the HMM arguments. What I like about Logan's >> proposal is to have a separate create and register steps dev_pagemap. >> That way call paths that don't care about HMM specifics can just turn >> around and register the vanilla dev_pagemap. > > Would you necessarily even need a create step? I was thinking more along > the lines that struct dev_pagemap _could_ just be a member in another > structure. The caller would set the attributes they needed and pass it > to devm_memremap. (Similar to how we commonly do things with struct > device, et al). Potentially, that could also get rid of the need for the > *data pointer HMM is using to get back the struct hmm_devmem seeing > container_of could be used instead. Also, now that I've thought about it a little more, it _may_ be that many or all of the hmm specific fields in dev_pagemap could move to a containing struct too... Logan