All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Matthew Wilcox <willy@infradead.org>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: (in)consistency of page/folio function naming
Date: Thu, 22 Apr 2021 11:09:45 +0200	[thread overview]
Message-ID: <ee5148a4-1552-5cf0-5e56-9303311fb2ef@redhat.com> (raw)
In-Reply-To: <20210422032051.GM3596236@casper.infradead.org>

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.

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2021-04-22  9:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-22  3:20 (in)consistency of page/folio function naming Matthew Wilcox
2021-04-22  9:09 ` David Hildenbrand [this message]
2021-04-22 12:21   ` Jason Gunthorpe
2021-04-22 13:41     ` Matthew Wilcox
2021-04-22 15:55   ` Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ee5148a4-1552-5cf0-5e56-9303311fb2ef@redhat.com \
    --to=david@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.