Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030735AbdDSSaL (ORCPT ); Wed, 19 Apr 2017 14:30:11 -0400 Received: from mail-yw0-f171.google.com ([209.85.161.171]:35222 "EHLO mail-yw0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S968942AbdDSSaI (ORCPT ); Wed, 19 Apr 2017 14:30:08 -0400 MIME-Version: 1.0 In-Reply-To: <99a22044-8f15-f381-19ee-e239e9d2da29@deltatee.com> 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> <99a22044-8f15-f381-19ee-e239e9d2da29@deltatee.com> From: Dan Williams Date: Wed, 19 Apr 2017 11:30:06 -0700 Message-ID: Subject: Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory To: Logan Gunthorpe Cc: Jerome Glisse , 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1558 Lines: 34 On Wed, Apr 19, 2017 at 11:19 AM, Logan Gunthorpe wrote: > > > 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... Yes, that's already how we handle struct page_map, it's an internal implementation detail of devm_memremap_pages(). Letting others users do the container_of() arrangement means that struct page_map needs to become public and move into struct dev_pagemap directly. ...I think that encapsulation loss is worth it for the gain of clearly separating the HMM-case from the base case.