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

[David Hildenbrand]

On 12.03.24 17:27, Max Kellermann wrote:
> On Tue, Mar 12, 2024 at 5:10 PM David Hildenbrand <david@xxxxxxxxxx> 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