Re: [PATCH V3] mm: Standardize printing for pgtable entries

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/9/26 12:09, Andy Shevchenko wrote:
> On Thu, Jul 09, 2026 at 11:12:58AM +0200, David Hildenbrand (Arm) wrote:
>> On 7/9/26 09:40, Andy Shevchenko wrote:
> 
>>>
>>> FWIW, you may move these to be after...
>>
>> We generally don't handle it like that in MM. Maybe one day we'll switch over
>> and document it accordingly.
>>
>> For now, having selected patches doing this differently is not any helpful.
> 
> Can you elaborate "differently"? Except a big noise and churn in the commit message
> I do not see any benefit of doing the "old" way. Lately I saw some patch-bot messages
> from Andrew, I assume he updates his scripts towards newer tooling, which may be
> a good sign that the (good) changes are still possible.

Take a look at the patches that go upstream from Andrew, where he still adds
additional Cc above his SOB.

We're planning a transition to a different mm model, as Andrew prepares for his
(partial :) ) retirement. We can discuss such things once the time has come, and
come to an agreement within the MM community.

This is not the time to have this discussion again, let's focus on the details
of the patch here, please.

> 
> [...]
> 
>>>
>>> The above is quite duplicative with what we have in lib/vsprintf.c. Have you considered
>>> using something from there instead? (Yes, it might require some functions to be wrapped
>>> or dropped from static.)
>>
>> Which part in particular do you have in mind?
>>
>> num_to_str() does not apply due to the u128.
>>
>> We could have u128 variant that we would only provide with __SIZEOF_INT128__
>>
>> int num128_to_str(char *buf, int size, u128 num, unsigned int width)
>>
>> And then have the code pass the value instead of a pointer to the value. A bit
>> tricky to handle this based on conditional __SIZEOF_INT128__ support, but could
>> be done.
>>
>> Not sure if that is really what we want here, though. ptval_bytes_to_hex_str()
>> is pretty ... simple :)
>>
>> I didn't immediately spot a replacement for PTVAL_STR_MAX.
> 
> I referred mostly to special_hex_number().

Only the .field_width = 2 + 2 * (size) in special_hex_spec() seems a bit related
(although different, because we don't want the leading 0x).

Like Petr says, I don't immediately see how this can easily be reused, but maybe
there is a way @Anshuman, @Petr

-- 
Cheers,

David