Message-ID: <43937a0a-679e-47e8-a4c5-d20759ef53c8@csgroup.eu>
Date: Mon, 24 Feb 2025 12:12:44 +0100
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Anshuman Khandual <anshuman.khandual@....com>, linux-mm@...ck.org
Cc: steven.price@....com, Catalin Marinas <catalin.marinas@....com>,
 Will Deacon <will@...nel.org>, Jonathan Corbet <corbet@....net>,
 Marc Zyngier <maz@...nel.org>, Michael Ellerman <mpe@...erman.id.au>,
 Nicholas Piggin <npiggin@...il.com>, Paul Walmsley
 <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
 Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, kvmarm@...ts.linux.dev,
 linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org,
 linux-s390@...r.kernel.org
Subject: Re: [PATCH 4/4] mm: Rename GENERIC_PTDUMP and PTDUMP_CORE



Le 14/02/2025 à 08:17, Anshuman Khandual a écrit :
> On 2/13/25 13:08, Christophe Leroy wrote:
>>
>>
>> Le 13/02/2025 à 05:09, Anshuman Khandual a écrit :
>>> Platforms subscribe into generic ptdump implementation via GENERIC_PTDUMP.
>>> But generic ptdump gets enabled via PTDUMP_CORE. These configs combination
>>> is confusing as they sound very similar and does not differentiate between
>>> platform's feature subscription and feature enablement for ptdump. Rename
>>> the configs as ARCH_HAS_PTDUMP and PTDUMP making it more clear and improve
>>> readability.
>>
>> For me GENERIC_PTDUMP is more explicit and similar to GENERIC_IOMAP or GENERIC_IOREMAP or GENERIC_GETTIMEOFDAY: The arch provides the necessary helpers to use the generic implementation.
> 
> I do realize that GENERIC_ is another method for achieving shared
> feature across multiple platforms via providing necessary helpers.
> But I guess there might be a difference - it might not have other
> similar but separate dependent configs ?
> 
>>
>> For me ARCH_HAS_PTDUMP just mean't that an architecture implements PTDUMP, it doesn't mean it does it by using the generic infrastructure.
> 
> ARCH_HAS_XXX indicates that an architecture subscribes to a generic
> feature XXX, by implementing all necessary helpers. But the feature
> in itself is a generic and a shared one.

I'm not sure about your interpretation.

For instance CONFIG_ARCH_HAS_ILOG2_U32 means that a plateform provides 
its own implementation. When this is _NOT_ defined, then the generic 
implementation is used instead.

> 
> If the platform were to implement a feature on its own without any
> generic component, it could do that via a separate platform specific
> config without requiring ARCH_HAS_XXX based subscription indication.

Not sure. Usually when a plateform needs something generic it subscribes 
to something like CONFIG_ARCH_WANT_GENERAL_HUGETLB


> 
>>
>> For instance, arm32 implements PTDUMP but without using the generic one so I would say that arm32 has PTDUMP and expect it to select ARCH_HAS_PTDUMP
> 
> Actually it does not need to select ARCH_HAS_PTDUMP, as it does not
> subscribe into generic PTDUMP. Let's see PTDUMP configs on arm (32)
> 
> ARM_PTDUMP_CORE
> ARM_PTDUMP_DEBUGFS	--> select ARM_PTDUMP_CORE
> ARM_DEBUG_WX 		--> select ARM_PTDUMP_CORE
> 
> The platform has a self contained PTDUMP implementation which does
> not depend on generic PTDUMP at all. Hence all these ptdump configs
> are marked as ARM_ etc as they are platform specific.

That's the reason why I believe the wording CONFIG_ARCH_HAS_SOMETHING is 
not appropriate.

Christophe

Powered by blists - more mailing lists