Re: [PATCH RFC 00/11] mm: distinguish PTE table storage from PTE values
"David Hildenbrand (Arm)" <[email protected]> Wed, 29 Jul 2026 14:28:25 +0200
| Newsgroups | gmane.comp.freedesktop.xorg.drivers.intel,gmane.linux.kernel,gmane.comp.video.dri.devel,gmane.linux.ports.parisc,gmane.comp.emulators.xen.devel,gmane.linux.kernel.mm,gmane.linux.file-systems,gmane.linux.kernel.cross-arch,gmane.linux.kernel.bpf,gmane.linux.kernel.perf.user |
|---|---|
| Message-ID | <[email protected]> |
On 7/29/26 14:21, Muhammad Usama Anjum wrote:
> On 29/07/2026 12:52 pm, David Hildenbrand (Arm) wrote:
>> On 7/29/26 13:33, Muhammad Usama Anjum wrote:
>>> Yeah and architecture cannot opt-in until its converted. So we should leave
>>> it to architecture to define hw_pte_t.
>>
>> In the context of this series, we should have something like an
>> CONFIG_ARCH_HAS_XXX and select the definition based on that.
>>
>> So we'd have a generic variant.
> I'll add CONFIG_ARCH_HAS_XXX config in generic version.
>
> I don't understand why generic code would define hw_pte_t if arch optionally
> opts-in.
>
> Are you saying pte_t may have different definition in different arches. But
> the hw_pte_t would always be structure of pte_t. Hence definition
>
> typedef struct { pte_t __pte; }; hw_pte_t;
>
> can be moved to the generic code?
>
> Moving definition to generic side is fine at this point in time. But if
> a arch wants to hw_pte_t opaque and don't want the generic code to perform
> arithmatic (ptep++), it'll not work.
Yes, but we can tackle this once some arch actually needs that. For now, it
makes this patch set easier to digest.
--
Cheers,
David