mm: opaque hardware page-table entry handles

[David Hildenbrand (Arm)]

> So after the conversion, it doesn't makes sense to keep STRICT_MM_TYPECHECKS
> around. Please correct me if I'm wrong.
> 
> This brings another thing in my mind that in ideal world we would just
> turn STRICT_MM_TYPECHECKS on for all arches all the time. But the problem
> with it is that STRICT_MM_TYPECHECKS defines pte_t which will stay double
> meaning still. So we want sort of STRICT_MM_TYPECHECKS with different name
> and separate stack and hardware types.

I think STRICT_MM_TYPECHECKS is also to avoid catching when passing a pte_t into
a function that consumes a pmd_t, and vice versa.

STRICT_MM_TYPECHECKS makes the compiler generate worse code today, which is why
we don't enable it always.

> 
>>
>> We would like to keep it, and I guess some other architectures too.
> David had summarized it well. We'll convert generic code to use hw_p*_t
> types which would be typedef to p*_t for those architectures which don't
> care about. But if an architecture wants to interpret these types
> differently or want to make sure the type is enforced and not directly
> dereferenced, they need to convert the arch code a well. But it can be
> done slowly.

I think what Alexander meant is: they want to keep STRICT_MM_TYPECHECKS (or
something that achieves something similar :) ). So as long as that keeps on
working, all good :)

-- 
Cheers,

David