Prepare to reduce dependencies in linux/mm.h.
Signed-off-by: Max Kellermann <[email protected]>
---
include/linux/mm.h | 20 +-------------------
include/linux/mm/folio_next.h | 27 +++++++++++++++++++++++++++
2 files changed, 28 insertions(+), 19 deletions(-)
create mode 100644 include/linux/mm/folio_next.h
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 778f8aebb45c..680329ec21ba 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2,6 +2,7 @@
#ifndef _LINUX_MM_H
#define _LINUX_MM_H
+#include <linux/mm/folio_next.h>
#include <linux/mm/page_address.h>
#include <linux/mm/page_section.h>
#include <linux/mm/page_size.h>
@@ -1902,25 +1903,6 @@ static inline void set_page_links(struct page *page, enum zone_type zone,
#endif
}
-/**
- * folio_next - Move to the next physical folio.
- * @folio: The folio we're currently operating on.
- *
- * If you have physically contiguous memory which may span more than
- * one folio (eg a &struct bio_vec), use this function to move from one
- * folio to the next. Do not use it if the memory is only virtually
- * contiguous as the folios are almost certainly not adjacent to each
- * other. This is the folio equivalent to writing ``page++``.
- *
- * Context: We assume that the folios are refcounted and/or locked at a
- * higher level and do not adjust the reference counts.
- * Return: The next struct folio.
- */
-static inline struct folio *folio_next(struct folio *folio)
-{
- return (struct folio *)folio_page(folio, folio_nr_pages(folio));
-}
-
/**
* folio_estimated_sharers - Estimate the number of sharers of a folio.
* @folio: The folio.
diff --git a/include/linux/mm/folio_next.h b/include/linux/mm/folio_next.h
new file mode 100644
index 000000000000..f92d649c42c6
--- /dev/null
+++ b/include/linux/mm/folio_next.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MM_FOLIO_NEXT_H
+#define _LINUX_MM_FOLIO_NEXT_H
+
+#include <linux/mm/page_address.h> // for nth_page(), needed by folio_page()
+#include <linux/mm/page_size.h> // for folio_nr_pages()
+
+/**
+ * folio_next - Move to the next physical folio.
+ * @folio: The folio we're currently operating on.
+ *
+ * If you have physically contiguous memory which may span more than
+ * one folio (eg a &struct bio_vec), use this function to move from one
+ * folio to the next. Do not use it if the memory is only virtually
+ * contiguous as the folios are almost certainly not adjacent to each
+ * other. This is the folio equivalent to writing ``page++``.
+ *
+ * Context: We assume that the folios are refcounted and/or locked at a
+ * higher level and do not adjust the reference counts.
+ * Return: The next struct folio.
+ */
+static inline struct folio *folio_next(struct folio *folio)
+{
+ return (struct folio *)folio_page(folio, folio_nr_pages(folio));
+}
+
+#endif /* _LINUX_MM_FOLIO_NEXT_H */
--
2.39.2
On Thu, Feb 15, 2024 at 03:55:55PM +0100, Max Kellermann wrote:
> Prepare to reduce dependencies in linux/mm.h.
I feel there's a lot more you could say here. Like "There are N files
which only include mm.h in order to use folio_next()". Otherwise ...
why is this more than churn?
On Thu, Feb 15, 2024 at 8:27 PM Matthew Wilcox <[email protected]> wrote:
> I feel there's a lot more you could say here. Like "There are N files
> which only include mm.h in order to use folio_next()".
You can see this detail in the last patch (14/14), but if you prefer
to have this spelled out here, I'll amend the patch description.
Though I only worked on the headers, not the thousands of sources
which might also be able to reduce their header dependencies. Getting
the exact number of those is a huge effort, and it's worth it, but not
today. Once this patch series is merged, we can incrementally start
this, but these patches are the precondition.
> Otherwise ...
> why is this more than churn?
This is about code correctness and faster compile times. You may or
may not value that, much of this is really just opinion. Similar
efforts have been merged recently, which is why I thought this goal
was consensus among kernel people.