On Tue, Mar 12, 2024 at 8:26 PM David Hildenbrand <david@xxxxxxxxxx> 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
