On 4/22/21 11:09 AM, 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. Agreed. > The only thing I'm concerned is that we end up with > > put_page vs. folio_put > > which is suboptimal. If we start differing from page's CamelCase, then we can start differing in this as well. Should be fine if the long-term goal is to convert as much from pages to folios as possible. Perhaps the remaining page usages could then be converted too for consistency as there won't be many left?
