On Wed, Apr 30, 2025 at 8:11 PM Zi Yan <ziy@xxxxxxxxxx> wrote:
>
> On 29 Apr 2025, at 22:40, Yafang Shao wrote:
>
> > On Tue, Apr 29, 2025 at 11:13 PM Zi Yan <ziy@xxxxxxxxxx> wrote:
> >>
> >> On Mon Apr 28, 2025 at 10:41 PM EDT, Yafang Shao wrote:
> >>> The functions hugepage_global_{enabled,always}() are currently only used in
> >>> mm/huge_memory.c, so we can move them to mm/internal.h. They will also be
> >>> exposed for BPF hooking in a future change.
> >>
> >> Why cannot BPF include huge_mm.h instead?
> >
> > To maintain better code organization, it would be better to separate
> > the BPF-related logic into dedicated files. It will prevent overlap
> > with other components and improve long-term maintainability.
>
> But at the cost of mm code maintainability? It sets a precedent that one
> could grow mm/internal.h very large by moving code to it. I do not think
> it is the right way to go.
I believe the helpers used exclusively by mm/ should be moved to
mm/internal.h. If the size of mm/internal.h is a concern, we could
consider introducing a separate mm/huge_internal.h.
That said, I won’t proceed with moving them to mm/internal.h if you
strongly believe it’s not appropriate—though personally, I don't think
avoiding it is the right direction.
--
Regards
Yafang
