Received-SPF: pass (google.com: domain of linux-kernel+bounces-100729-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240312094133.2084996-1-max.kellermann@ionos.com>
 <58fbe42a-3051-46bf-a3f9-d59da28a9cd7@redhat.com> <CAKPOu+8AQ8g_bEOBRoLiiO6eYBGj09YiUx=U0QPnB0Csifa6xw@mail.gmail.com>
 <37ed1ddd-f1d0-4582-b6c5-2f4091dc8335@redhat.com> <CAKPOu+_EwyQEEVV9ULEkncp3727eLGvqD5aswpkG5CtaZ=oJBQ@mail.gmail.com>
 <f959c4c4-8118-436c-83fd-d299689f753a@redhat.com>
In-Reply-To: <f959c4c4-8118-436c-83fd-d299689f753a@redhat.com>
From: Max Kellermann <max.kellermann@ionos.com>
Date: Tue, 12 Mar 2024 20:50:55 +0100
Message-ID: <CAKPOu+-SMvjfyNGO-Dt8SahF3TOmLaLFE_yP+KQxk0wdHpFeWQ@mail.gmail.com>
Subject: Re: [PATCH v4 00/15] Fast kernel headers: split linux/mm.h
To: David Hildenbrand <david@redhat.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org, 
	linux-kernel@vger.kernel.org, willy@infradead.org, sfr@canb.auug.org.au
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 12, 2024 at 8:26=E2=80=AFPM David Hildenbrand <david@redhat.com=
> wrote:
> It's always a good idea to include at least some sentences about
> history+motivation in the cover letter.

Agree, thanks for your review and for the suggestions, that was very
useful. Once somebody points it out, it's suddenly obvious what was
missing in my explanations for others to understand my motivation.
I'll add some more text to the cover letter.

> Okay, so "Fast kernel headers:" is a bit misleading :P

Yeah. It was the name chosen by Ingo Molnar for his header cleanup
project, and some of his work was merged several years ago, so I
thought this phrase would be familiar and would bring back memories
from these discussions.

> (although I don't immediately understand what correctness means in this
> context)

Some sources don't include all the headers they need; but by chance,
this happens to work because deep down the include tree, somebody
includes kernel.h, mm.h or fs.h and that pulls in everything else;
thus incorrect includes are never a visible problem. By reducing
includes to the bare minimum, many of those problems are revealed (by
producing compiler errors that then have to be fixed). I very much
like to write code in a way that the compiler points out some kinds of
mistakes - I rather have a build-time error than a silent runtime
breakage.

Incorrect includes are not just a theoretical problem; imagine all the
asm-generic headers that provide fallback definitions for macros that
are not defined on some architectures (e.g. asm-generic/cacheflush.h).
If, on some sources, the arch-specific header happens to be not
included or defines the macro in the wrong header (I've seen it all),
you suddenly randomly get the correct arch macro or the generic
fallback macro, leading to inconsistencies, hidden ABI breakages that
may lead to severe problems that will be hard to debug. One can
imagine many more ways that code can break silently at runtime due to
incorrect code (that usually works most of the time, but only by
chance). Better be explicit about what you really need to include, and
don't rely on other headers to indirectly include what you need.
Include what you need even if somebody else down the tree had already
included it, because that somebody else may change his mind at some
point, and then your source shouldn't break.

> The problem I see
> is that once your stuff is merged, it will start getting messed up again
> over time. But maybe that's just the way it works.

It is. This is like cleaning your house: the following day, somebody
visits you and brings nice presents (feature patches) but has dirty
shoes, and then you have to clean the house again... that's the
infinite cycle of software development, as we all know it.

Max