Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp1045380rwr; Wed, 3 May 2023 09:28:03 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7dUCtW1N44ddK1xpt95lsQVpaqB115IxFxduO4KQNuXevCiQ/BL2Ngex+c4Sjq/nNjpUfa X-Received: by 2002:a05:6a00:2e18:b0:62d:8376:3712 with SMTP id fc24-20020a056a002e1800b0062d83763712mr24224069pfb.28.1683131283202; Wed, 03 May 2023 09:28:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683131283; cv=none; d=google.com; s=arc-20160816; b=mrzsXyaRTgfSFHGQKMd5NmBfibYrq9FE2X5HlzvjC4/W3pvncA5tMFtMuybAWsXS8p ScB40YB4VB32XWyg8f/wV4NhhZuidwHBO83IxGpGzfqAyXCRBb5ceVZ57G4eqnavjtEJ txKefXxpmhqF0wwZafCuDfg3VxmEx1kVRSp/n1/32pUxLQZnNJJhBefI5PMM1foaGqhV XeYvrEYKQBCMM6YtonBmwbwMl9Kqp7Q4NYcqMOCiAEG0c1vJg5+eZlXFkLQiowgRNi+S VxvTpmh311tEkzVoxqiLzplgi526UKfwDJNy9GVhZqs5HBZkd7TZeHkcknXTQpa6afKt ChQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=Jm1bkZocqyd6R6rrU0g//mDZBCV/K0TFLICtX6a6fKE=; b=aN95iKfHtE8yvT4AQBskGE5G1yfJ9gbJU+/U4IR4swtBZDFbn5p+zYTgKr3C8JBKpm 33v5rh6VZ92nyW58RABhHA9/jqQ056nQ/rU09TPOtxPnl1lfVNM4Q2dE0RdxnslcuQUt RbpMOHmtxpUmqIOO6bqoeo2ZbgGNpSrxQIvMINLDoY4+l0s3BLver3ylAK5fQkFIbO9T Y2Z1tdbQCKyDmbl1nSdmkIDgZi3RW73nvhtL3Dcng39dNpPsZsj2wwAXV/HsNTTXcB24 qiIoC/G+DOxAXtBwMzG1+f/VH3FMDpWRFOTV+ZK2/nOKXRBzhwsr1aTkCCh9g6NOQ0Iv Putw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n127-20020a632785000000b0050c0cdce84asi36537699pgn.577.2023.05.03.09.27.49; Wed, 03 May 2023 09:28:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229588AbjECQZn (ORCPT + 99 others); Wed, 3 May 2023 12:25:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229559AbjECQZk (ORCPT ); Wed, 3 May 2023 12:25:40 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 933805258; Wed, 3 May 2023 09:25:39 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1CBA362EA8; Wed, 3 May 2023 16:25:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5712FC433EF; Wed, 3 May 2023 16:25:31 +0000 (UTC) Date: Wed, 3 May 2023 12:25:29 -0400 From: Steven Rostedt To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, ldufour@linux.ibm.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Subject: Re: [PATCH 19/40] change alloc_pages name in dma_map_ops to avoid name conflicts Message-ID: <20230503122529.44ef2d56@gandalf.local.home> In-Reply-To: <20230501165450.15352-20-surenb@google.com> References: <20230501165450.15352-1-surenb@google.com> <20230501165450.15352-20-surenb@google.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 1 May 2023 09:54:29 -0700 Suren Baghdasaryan wrote: > After redefining alloc_pages, all uses of that name are being replaced. > Change the conflicting names to prevent preprocessor from replacing them > when it's not intended. Note, every change log should have enough information in it to know why it is being done. This says what the patch does, but does not fully explain "why". It should never be assumed that one must read other patches to get the context. A year from now, investigating git history, this may be the only thing someone sees for why this change occurred. The "why" above is simply "prevent preprocessor from replacing them when it's not intended". What does that mean? -- Steve > > Signed-off-by: Suren Baghdasaryan