From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 631F7C0044C for ; Wed, 7 Nov 2018 20:36:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 20A9820837 for ; Wed, 7 Nov 2018 20:36:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 20A9820837 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=deltatee.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726996AbeKHGIs (ORCPT ); Thu, 8 Nov 2018 01:08:48 -0500 Received: from ale.deltatee.com ([207.54.116.67]:49686 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726611AbeKHGIs (ORCPT ); Thu, 8 Nov 2018 01:08:48 -0500 Received: from guinness.priv.deltatee.com ([172.16.1.162]) by ale.deltatee.com with esmtp (Exim 4.89) (envelope-from ) id 1gKUZ1-0005qg-46; Wed, 07 Nov 2018 13:36:35 -0700 To: Thomas Gleixner Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-riscv@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-sh@vger.kernel.org, Stephen Bates , Palmer Dabbelt , Albert Ou , Christoph Hellwig , Arnd Bergmann , Michal Hocko , Vlastimil Babka , Oscar Salvador References: <20181107173859.24096-1-logang@deltatee.com> <20181107173859.24096-3-logang@deltatee.com> <20181107121207.62cb37cf58484b7cc80a8fd8@linux-foundation.org> <724be9bb-59b6-33f3-7b59-3ca644d59bf7@deltatee.com> From: Logan Gunthorpe Message-ID: Date: Wed, 7 Nov 2018 13:36:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.162 X-SA-Exim-Rcpt-To: osalvador@suse.de, vbabka@suse.cz, mhocko@suse.com, arnd@arndb.de, hch@lst.de, aou@eecs.berkeley.edu, palmer@sifive.com, sbates@raithlin.com, linux-sh@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, tglx@linutronix.de X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [PATCH 2/2] mm/sparse: add common helper to mark all memblocks present X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-11-07 1:26 p.m., Thomas Gleixner wrote: > Logan, > > On Wed, 7 Nov 2018, Logan Gunthorpe wrote: >> On 2018-11-07 1:12 p.m., Andrew Morton wrote: >>>> +void __init memblocks_present(void) >>>> +{ >>>> + struct memblock_region *reg; >>>> + >>>> + for_each_memblock(memory, reg) { >>>> + memory_present(memblock_get_region_node(reg), >>>> + memblock_region_memory_base_pfn(reg), >>>> + memblock_region_memory_end_pfn(reg)); >>>> + } >>>> +} >>>> + >>> >>> I don't like the name much. To me, memblocks_present means "are >>> memblocks present" whereas this actually means "memblocks are present". >>> But whatever. A little covering comment which describes what this >>> does and why it does it would be nice. >> >> The same argument can be made about the existing memory_present() >> function and I think it's worth keeping the naming consistent. I'll add >> a comment and resend shortly. > > Actually if both names suck, then there also is the option to rename both > instead of adding a comment to explain the suckage. Ok, well, I wasn't expecting to take on a big rename like that as it would create a patch touching a bunch of arches and mm files... But if we can come to some agreement on a better name and someone is willing to take that patch without significant delay then I'd be happy to create the patch and add it to the start of my series. Some ideas for new names: mark_memory_present() / mark_memblocks_present() set_memory_present() / set_memblocks_present() memory_register() / memblocks_register() register_memory() / register_memblocks() Logan