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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 D6664C2BA19 for ; Sat, 11 Apr 2020 20:58:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7937F2084D for ; Sat, 11 Apr 2020 20:58:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="d38VMacm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7937F2084D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 08BD08E00B0; Sat, 11 Apr 2020 16:58:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 03C238E0007; Sat, 11 Apr 2020 16:58:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6D098E00B0; Sat, 11 Apr 2020 16:58:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0009.hostedemail.com [216.40.44.9]) by kanga.kvack.org (Postfix) with ESMTP id CEA7F8E0007 for ; Sat, 11 Apr 2020 16:58:16 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 82F90A8ED for ; Sat, 11 Apr 2020 20:58:16 +0000 (UTC) X-FDA: 76696786992.09.snail19_654d9d9fa3226 X-HE-Tag: snail19_654d9d9fa3226 X-Filterd-Recvd-Size: 5712 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Sat, 11 Apr 2020 20:58:16 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id k21so5225506ljh.2 for ; Sat, 11 Apr 2020 13:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eWYOxbXFRnbNvAiB3r8nYDFiXyRHEzA+YDF9hheoCek=; b=d38VMacm5CC5OO6PkiOjO+BmV1qUgyaDDCExE9nJj04S8R8ZwUN0ijSLBpjR9kG73i e2H+lVwaVML/nJgrm+owTR9pLMhaaGbA+Fp3vWA06siDzigMBK4wCw4Vmyc4WCSJaqxE J1zxKymqjHSdEO1H49jzOWxRMaUDOJSreZ3oQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eWYOxbXFRnbNvAiB3r8nYDFiXyRHEzA+YDF9hheoCek=; b=DKkziVjf0oEl6MvhMv3RjgbUEInkSwwfn9WgMkuO3E1R7iNJtto00S1WibfhKaP/GA x4DJH3OSHGVpmgwe1DTkNG17lYdt4BB7GkFjMgzGmsYazqw2rL8fL54Mqrnw7vk8mgNR XPBtDsKt7XSSNfSDaoPjPyGOpY9legAiWKfIalczxZ2j8gVTOfk+yRAKZs3e21e5eSWd U7pcCr+L3/J4gE+AGJCKrDnXPfFhcjMqIQC81FMSyMsRq6Fcs6OlTbVKR0bAiJpEnA52 RJknhBrTULgBxZ7iE23wjU5HqRa+wrbeqMcKgsSPXDjJFWVl9JyAC1WcvcqYZ9WwG/Z5 6IHA== X-Gm-Message-State: AGi0PuZVV47k96opIrGasLp+y9mNleHv0Myvd3XK2pHU3EoNeTSIUjae i4yzfdnTCq5mxQGwZ7MetB3X6ga6vLU= X-Google-Smtp-Source: APiQypLINhg0o8jEg07BcRuOnSuwXFTdb/iNpkNvF2qO80M17bQbxYJDl+TriMv3tznBzUfOWxDWGQ== X-Received: by 2002:a2e:95d4:: with SMTP id y20mr3154459ljh.246.1586638694176; Sat, 11 Apr 2020 13:58:14 -0700 (PDT) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com. [209.85.167.42]) by smtp.gmail.com with ESMTPSA id f21sm4541194lfk.94.2020.04.11.13.58.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Apr 2020 13:58:13 -0700 (PDT) Received: by mail-lf1-f42.google.com with SMTP id 198so3751947lfo.7 for ; Sat, 11 Apr 2020 13:58:13 -0700 (PDT) X-Received: by 2002:a19:7706:: with SMTP id s6mr6058553lfc.31.1586638692669; Sat, 11 Apr 2020 13:58:12 -0700 (PDT) MIME-Version: 1.0 References: <20200411203220.GG21484@bombadil.infradead.org> In-Reply-To: <20200411203220.GG21484@bombadil.infradead.org> From: Linus Torvalds Date: Sat, 11 Apr 2020 13:57:56 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] Rename page_offset() to page_pos() To: Matthew Wilcox Cc: linux-fsdevel , Linux-MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" 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 Sat, Apr 11, 2020 at 1:32 PM Matthew Wilcox wrote: > > We've had some trouble recently with page_offset() being confusingly > named. This makes little sense to me. I don't find "page_pos()" to be in the least more intuitive than "page_offset()". Yes, you have some numbers of "offset" vs "pos" being used for the position in the file, but they aren't _that_ different, and honestly, if you look at things like the man-page for "lseek()", the byte offset you seek to is called an "offset". The fact that somebody was confused by the current name is a red herring - there's nothing to say that they wouldn't have been confused by "page_pos()", except for the fact that that wasn't the name. So honestly, i the confusion is that we have "pgoff_t", which is the offset of the page counted in _pages_, then my reaction is that (a) I think the truly confusing name is "pgoff_t" (and any "page_offset" variable of that type). Calling that "pgindex_t" and "page_index" would be a real clarification. (b) if we really do want to rename page_offset() because of confusion with the page index "offset", then the logical thing would be to clarify that it's a byte offset, not the page index. So "page_pos()" to me sounds not at all more descriptive, and having two names (for stable kernels, for people with memories, for historical patches, whatever) only sounds like a source of even more confusion in the future. If we'd want a _descriptive_ name, then "byte_offset_of_page()" would probably be that. That's hard to mis-understand. Yes that's also more of a mouthful, and it still has the "two different names for the same thing" issue wrt stable/old/rebased/whatever patches. But if there are enough people who find "page_offset()" to be a source of confusion, then I'd at least prefer to _truly_ remove any possibility of confusion with that longer name. I'd like to have a few more people step up and say "I find that name confusing enough that I think it's worth the confusion of renaming it". We've had the "page_offset()" name _forever_, this is the first time I hear it being a problem (it goes back to 2005, and before that it was used inside the NFS code). Of course, we've also had "pgoff_t" forever - that name goes back to 2002. But unlike "page_offset()", I do think that "pgoff_t" is actually a truly bad name. Which is why I'd much rather change "pgoff_t" to "pgindex_t" and related "page_offset" variables to "page_index" variables. Linus