Re: [PATCH v4 00/15] Fast kernel headers: split linux/mm.h

David Hildenbrand
2024-03-12T16:32:44Z

On 12.03.24 17:27, Max Kellermann wrote:
> On Tue, Mar 12, 2024 at 5:10 PM David Hildenbrand <david@redhat.com> wrote:
>>> include/linux/mm.h | 583 +-----------------
>>> include/linux/mm/devmap_managed.h | 37 ++
>>> include/linux/mm/folio_next.h | 27 +
>>
>> Isn't that a bit excessive? Do we really need that many folio headers?
>
> It would technically be possible to have fewer headers by merging
> several of those headers back into one, but then the dependencies will
> be heavier, and eventually we'd be back at the large "mm.h" mess that
> I would like to get rid of.

Just curious: why? Usually build time, do you have some numbers?

> My patch set constitutes the balance of "not too many headers" vs
> "small set of unnecessary dependencies for each including source file"
> according to my taste.

I'm not against splitting out stuff. But one function per header is a
bit excessive IMHO. Ideally, we'd have some MM guideline that we'll be
able to follow in the future. So we don't need "personal taste".

For example, if I were to write a folio_prev(), should I put it in
include/linux/mm/folio_prev.h ? Likely we'd put it into folio_next.h,
but then the name doesn't make any sense.

The point I am trying to make: if there was a single folio_ops.h, it
would be clearer where it would go.

Just my 2 cents, seeing one-function-per-file headers.

--
Cheers,

David / dhildenb