linux-kernel - Re: [PATCH v1 07/14] linux/mm.h: move folio_next() to mm/folio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 15 Feb 2024 20:41:04 +0100
From: Max Kellermann <max.kellermann@...os.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 07/14] linux/mm.h: move folio_next() to mm/folio_next.h

On Thu, Feb 15, 2024 at 8:27 PM Matthew Wilcox <willy@...radead.org> 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.