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

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]

Message-ID: <37ed1ddd-f1d0-4582-b6c5-2f4091dc8335@redhat.com>
Date: Tue, 12 Mar 2024 17:32:37 +0100
From: David Hildenbrand <david@...hat.com>
To: Max Kellermann <max.kellermann@...os.com>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, willy@...radead.org, sfr@...b.auug.org.au
Subject: Re: [PATCH v4 00/15] Fast kernel headers: split linux/mm.h

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