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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F3D6C77B78 for ; Wed, 3 May 2023 16:25:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 39B2F6B0075; Wed, 3 May 2023 12:25:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 34B976B0078; Wed, 3 May 2023 12:25:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 212726B007B; Wed, 3 May 2023 12:25:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by kanga.kvack.org (Postfix) with ESMTP id 079A96B0075 for ; Wed, 3 May 2023 12:25:40 -0400 (EDT) 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 0C4866259B; 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-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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