From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2A9DC2129F10F for ; Fri, 21 Jun 2019 13:35:53 -0700 (PDT) Received: by mail-ot1-x341.google.com with SMTP id x21so7497858otq.12 for ; Fri, 21 Jun 2019 13:35:53 -0700 (PDT) MIME-Version: 1.0 References: <155993563277.3036719.17400338098057706494.stgit@dwillia2-desk3.amr.corp.intel.com> <155993567002.3036719.5748845658364934737.stgit@dwillia2-desk3.amr.corp.intel.com> <20190607202332.GB32656@bombadil.infradead.org> In-Reply-To: <20190607202332.GB32656@bombadil.infradead.org> From: Dan Williams Date: Fri, 21 Jun 2019 13:35:42 -0700 Message-ID: Subject: Re: [PATCH v3 07/10] lib/memregion: Uplevel the pmem "region" ida to a global allocator List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Matthew Wilcox Cc: X86 ML , Ard Biesheuvel , Peter Zijlstra , Dave Hansen , Linux Kernel Mailing List , linux-nvdimm , linux-efi List-ID: On Fri, Jun 7, 2019 at 1:23 PM Matthew Wilcox wrote: > > On Fri, Jun 07, 2019 at 12:27:50PM -0700, Dan Williams wrote: > > diff --git a/lib/memregion.c b/lib/memregion.c > > new file mode 100644 > > index 000000000000..f6c6a94c7921 > > --- /dev/null > > +++ b/lib/memregion.c > > @@ -0,0 +1,15 @@ > > +#include > > + > > +static DEFINE_IDA(region_ids); > > + > > +int memregion_alloc(gfp_t gfp) > > +{ > > + return ida_alloc(®ion_ids, gfp); > > +} > > +EXPORT_SYMBOL(memregion_alloc); > > + > > +void memregion_free(int id) > > +{ > > + ida_free(®ion_ids, id); > > +} > > +EXPORT_SYMBOL(memregion_free); > > Does this trivial abstraction have to live in its own file? I'd make > memregion_alloc/free static inlines that live in a header file, then > all you need do is find a suitable .c file to store memregion_ids in, > and export that one symbol instead of two. Ok, I think since these "memregion" objects tend to be closely related to "device memory" I'll stash this in kernel/memremap.c with the rest of the "ZONE_DEVICE" apis. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm