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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 91DA9C433ED for ; Thu, 22 Apr 2021 12:21:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D32D66144E for ; Thu, 22 Apr 2021 12:21:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D32D66144E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 41E136B006C; Thu, 22 Apr 2021 08:21:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CE2B6B0070; Thu, 22 Apr 2021 08:21:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BD986B0071; Thu, 22 Apr 2021 08:21:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0100.hostedemail.com [216.40.44.100]) by kanga.kvack.org (Postfix) with ESMTP id 0BF5B6B006C for ; Thu, 22 Apr 2021 08:21:20 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C2FF78248047 for ; Thu, 22 Apr 2021 12:21:19 +0000 (UTC) X-FDA: 78059913078.02.B879FFB Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by imf11.hostedemail.com (Postfix) with ESMTP id B2C472000242 for ; Thu, 22 Apr 2021 12:21:05 +0000 (UTC) Received: by mail-qk1-f169.google.com with SMTP id 8so12251489qkv.8 for ; Thu, 22 Apr 2021 05:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qVWrfQzUOT2W5T6LzCbeZXCDM93ivBP3SLZzFzlfi4E=; b=Ua3mkPD/Xz9lzWvgIzVY3P//fV1gr9BbsHlBhhjqwmXmajXfImTOzvXIzBwM8Z1Lu9 X+tqw5PKqwgg/STXozh3785Y7GuSKT8xJP3YqLUlEz1MS7Ig5ksTLOYIjKuabNevAxrP o9YJDw+2dvkU8YWpD5M0duw9U/2YEQ94ZrFuNq/AljCHbyJuG2J6gBcCPRuODL5PNPcS WlQKaPfhGLu9jysxZOGvwpU/5giO0guXha2TJWgVPDRIc7V9di2fSayGB6T7rAga8ZRM +Mpw7dBzGk2fjMJugMz/RHOSZ5yIjO4nUTChSqGe6RLQPhX8x6zvV+Fx9GhuUS6ogY3y nwnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qVWrfQzUOT2W5T6LzCbeZXCDM93ivBP3SLZzFzlfi4E=; b=JaC4fwPKuFSESZ5KCSjum3gYGGbSVd7Zg3H/1kGB8e1an+L6r5OK+ofOfqwZ/ENdXb z060iPJbTFAZgltFwGEcABWhDVhnetJIArb84KJTX3Qzi28BiwKw283TxouWWBbRZKoc luset4wnhLPEKJU1DKDsjtI/xyipqc3jrLyROW6YZkc/VlXpD7kc8BhbgdiHfz9iZVgN X4Zg0LoqJEN+vn9U3bIYWmhUHh+tD7O+85ORJd2y+gMavTs0zYHHbfkhd2MPJZbiSPS1 LXHEgjMAmX7VCRctzCMN1nyZJ2n7E46ALtypvMk0TmZ028lZUD1ymoMaIrOBAmuQDC/Y amtg== X-Gm-Message-State: AOAM531/aF+rDfW88NseYVsUhOQuX4aGqeLGAiQjvvLZnIK1gI04yOjR pJWaFOgFEcPFasnro9ihzwPx7Q== X-Google-Smtp-Source: ABdhPJzwE+9aeUZVBpFovriagH/KNZxNHbpOUz5vHV6OomQkhIlD0Qo0haX5OGY5XKqAyn+WCHqMgA== X-Received: by 2002:a37:c57:: with SMTP id 84mr3406814qkm.340.1619094078598; Thu, 22 Apr 2021 05:21:18 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-47-55-113-94.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.113.94]) by smtp.gmail.com with ESMTPSA id w67sm2044765qkc.79.2021.04.22.05.21.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Apr 2021 05:21:18 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1lZYKb-009xA0-8R; Thu, 22 Apr 2021 09:21:17 -0300 Date: Thu, 22 Apr 2021 09:21:17 -0300 From: Jason Gunthorpe To: David Hildenbrand Cc: Matthew Wilcox , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: (in)consistency of page/folio function naming Message-ID: <20210422122117.GE2047089@ziepe.ca> References: <20210422032051.GM3596236@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: otk9d5k46b75y7unwjci3izrp54gnwhr X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B2C472000242 Received-SPF: none (ziepe.ca>: No applicable sender policy available) receiver=imf11; identity=mailfrom; envelope-from=""; helo=mail-qk1-f169.google.com; client-ip=209.85.222.169 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619094065-779394 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000010, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 22, 2021 at 11:09:45AM +0200, David Hildenbrand wrote: > On 22.04.21 05:20, Matthew Wilcox wrote: > > > > I'm going through my patch queue implementing peterz's request to rename > > FolioUptodate() as folio_uptodate(). It's going pretty well, but it > > throws into relief all the places where we're not consistent naming > > existing functions which operate on pages as page_foo(). The folio > > conversion is a great opportunity to sort that out. Mostly so far, I've > > just done s/page/folio/ on function names, but there's the opportunity to > > regularise a lot of them, eg: > > > > put_page folio_put > > lock_page folio_lock > > lock_page_or_retry folio_lock_or_retry > > rotate_reclaimable_page folio_rotate_reclaimable > > end_page_writeback folio_end_writeback > > clear_page_dirty_for_io folio_clear_dirty_for_io > > > > Some of these make a lot of sense -- eg when ClearPageDirty has turned > > into folio_clear_dirty(), having folio_clear_dirty_for_io() looks regular. > > I'm not entirely convinced about folio_lock(), but folio_lock_or_retry() > > makes more sense than lock_page_or_retry(). Ditto _killable() or > > _async(). > > > > Thoughts? > > I tend to like prefixes: they directly set the topic. > > The only thing I'm concerned is that we end up with > > put_page vs. folio_put > > which is suboptimal. We have this issue across the kernel already, eg kref_put() vs its wrapper put_device() Personally I tend to think the regularity of 'thing'_'action' is easier to remember than to try to guess/remember that someone judged 'action'_'thing' to be more englishy. Jason